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ABSTRACT 


An important problem in software development process is to make better use of 
software libraries by improving the search and retrieval process, that is, by making it easier to 
find the few components you may want among the many you do not want. The problem with the 
current production approaches is that they do not consider the behavior of components as a part 
of the retrieval process. As the result, it is impossible to obtain high recall and precision. In 
contrast, research approaches using syntactic and specification can be used to improve upon 
recall and precision. However, these approaches require a lot more computational effort 
Without a library structure to support a retrieval process, they would be impractical. This 
dissertation concentrates on two themes. First, how to provide efficient and effective retrieval 
capabilities and an interactive friendly interface to support users to search for software 
components. Second, how to construct a library that can assist the librarian with cataloging 
software components and help to facilitate the search process. The first prototype has been 
implemented to verify the proposed ideas. Several studies have been performed in to measure 
the system performance. The result confirms and strongly supports the proposed ideas. 
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I. INTRODUCTION 


Billions of dollars are spent each year on computer software. Much of this effort 
is spent on creating and testing new source code. In order to save money, increase 
productivity, and improve reliability, the Department of Defense is constructing 
repositories of reusable software components that can be used across applications. 
Devising an effective way to retrieve components from software libraries, referred to as 
the Software Component Search problem (or simply, the Search Problem), is of 
increasing importance for many applications. For example, rapid prototyping has been 
used to validate and refine system requirements, and check the consistency of proposed 
designs, before undertaking a full implementation. Automated retrieval of relevant 
reusable software components is important for this area. 

The problem with the current production approaches is that they do not consider 
the behavior of components as part of the retrieval process. As the result, it is impossible 
to obtain high recall and precision. In contrast, the research approaches using syntactic 
and specification can be used to improve upon recall and precision. However, they 
require a lot more computational effort. Without a library structure to support a retrieval 
process, these approaches would be impractical. This dissertation concentrates on two 
themes. First, how to provide efficient and effective retrieval capabilities and an 
interactive friendly interface to support users to search for components. Second, how to 
construct a library that can assist the librarian with cataloging components and help to 
facilitate the search process. 
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In practice, there may be no component in the software base that does exactly 
what is wanted, but there may be some component that can be easily modified to do the 
job. This implies that given a query, we do not just seek components that match it 
exactly, but instead we seek a set of approximate candidates, ordered by how well they 
match the query. In other words, the choice set should consist of ranked partial matches. 

These considerations motivate the following requirements for solutions to the 
search problem: 

• The retrieval process should be automated, since a software library may con¬ 
tain thousands of components, so that it would be virtually impossible for a 
human being to identify the desired component(s) quickly and accurately. 

• The retrieval process should be accurate, in the sense that the choice set should 
include the closest match, if there is one. 

• The search process should be effective, in that it should be fast, and the choice 
set should not be too large. 

• The user interface should allow flexible, easy query formulation, and should 
provide helpful feedback to the user. 

Professor Luqi [19, 22] has suggested associating a semantic specification with 
each module in the software base to support retrieval against semantic queries, as has 
Professor Goguen [7]. This idea has been shown viable in work reported in [21, 32, 33], 
where the algebraic specification language OBJ3 [6, 10, 16] was used in software search 
experiments in the context of the Computer Aided Prototyping System (CAPS) project. 
Recent work [14] has carried this further by showing how to treat generic modules, how 
to use semantic information in a limited efficient way, and how to rank candidate 
modules by their likelihood of success (see [33] for discussion of an earlier ranking 
method). Ranking modules by how well they satisfy the query makes the search process 
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more robust, that is, better able to tolerate errors in the query and in how components are 
classified. We must expect such errors in practice. 

Given a query Q and a component M with corresponding specification then 

A/ is a correct answer for the query Q if there is a translation of the syntax of Q into the 

syntax of 7^ such that each translated equation from 0 is a consequence^ of 7^. Finding 
a correct answer in this sense is really a theorem proving task that could take too much 
time to be practical if not limited. However, finding candidates that satisfy adequate 
necessary conditions for being a correct answer is a practical goal. This will allow many 
irrelevant candidates to be rejected, resulting in a more focused search and raising the 
confidence in the components found. 

A brief summary of related work is given in Chapter II. An overview of our 
software architecture for automated component retrieval is given in Chapter III. 
Background information on algebraic specification, including basic definitions, is given 
in Appendix A. Chapters IV and V describe syntactic and semantic filtering, 
respectively. Examples illustrating the search process are given in Chapter VI, while 
Chapter VII gives an overview of the structure of the design of the prototype. Chapter 
Vni provides the experimental results. Finally, Chapter IX summarizes the dissertation 
and proposes directions for further work. 


1. Such consequences may be either equational consequences or inductive consequences, depend¬ 
ing of whether a “loose” or an “initial” semantics is given to the specification (these terms 
are explained in [26]). An advantage of our approach is that it is insensitive to which of these 
semantics is assumed. 
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II. BACKGROUND AND RELATED WORK 


Previous work on reusable software component retrieval can be classified as 
classical, facet oriented, AI, or pure specification. More information may be found in [5, 
4, 17, 19, 25, 29], We do not attempt to survey the entire relevant literature here, but 
instead we first describe some publications that seem most closely related to the present 
work. 

A. CLASSICAL APPROACHES 

The most classical approach to retrieval is to classify items by keywords, and then 
search for items that have certain given keywords [23]. Experience shows that this works 
poorly for retrieving software components from even moderately large libraries. One 
problem is that the user must be familiar with both the classification scheme and the par¬ 
ticular library. Also, it is very difficult to get both high precision and high recall^. This 
suggests that for ranked filtering, it would be most appropriate to use a small number of 
keywords. 

Another classical approach is browsing. Browsing systems depend on links among 
the items to be searched, and upon the user following those links to find the desired item. 
Experience shows that browsing through large structures can be very frustrating and time- 
consuming. Often, existing links seem random or even perverse, while the links you really 
want may not be present. 


2. Precision and recall are classical terms from information retrieval. Let Q be the set of items that 
should be returned in answer to the query and let R be the choice set actually returned. Then the 

precision of R is defined to be \R r\Q\/\Q\ while the recall of R is \Rr^Q\/ 1/?|. 
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B. THE FACET APPROACH 

Prieto-Diaz [30] has proposed \xs\n% facets, which are groups of related terms in a 
subject area. For example, a facet to describe the functions performed by components 

might use terms chosen from find, compare, sort, update, send, receive .A scheme is 

developed in [30] to describe Unix components using four facets: the function performed 
by the component, the objects that are manipulated, the data structure used, and the system 
to which the function belongs. This provides a better description of Unix components than 
a pure keyword approach due to its well-structured. However, it still relies on an informal 
description of components, using a limited set of facets and terms. Facet is also suffering 
the same problem as Keyword approach. Namely, it also tends to miss potentially useful 
components because the people who classify the components in the library cannot antici¬ 
pate all potential applications of each component. 

C AI APPROACHES 

Al-based work includes [3,27] and some recent work by Henninger [18], which 
uses a knowledge-base and statistical information to retrieve reusable components, based 
on keyword search from texts describing the components. However, because the 
characterization of the component behavior is completely informal, the behavior is 
unpredictable. 

D. SPECIFICATION-BASED APPROACHES 

Recent work using semantics for software component retrieval is reported in [19, 
25]. The primary aim is to check that retrieved components yield the behavior specified 
in the user's query, therefore increasing the precision of retrieval. Using formal 
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specifications as search keys has two main problems. The first problem is practical; not 
all users are sophisticated enough to write formal specifications, much less correct ones. 
The second problem is that semantic matching is very time consuming, because some 
form of theorem proving must be done. 

The Venari^ project at Carnegie Mellon University, headed by Prof Jeannette 
Wing, is devoted to retrieving components from software libraries, and has produced a 
number of interesting publications. Here we will not discuss their work on transactions 
and other infrastructural support for retrieval, but only their work on the search problem. 
Rollins and Wing [31] discuss signature matching for retrieving higher-order 

functions from an MetaLanguage (ML) library'*, using A,Prolog for matching user 
queries to component signatures. XProlog is used to implement various matching 

modulo theories, in order to support (what we call) partial matches^. They also use 
A.Prolog to check simple pre- and post- conditions for ML functions. Although this paper 
demonstrates that higher-order logic is useful for such applications, we feel that higher- 
order logic is more powerful and expressive than necessary, and that higher-order logic 
tools like A,Prolog are too inefficient. Of course, a higher-order language like ML 
requires the use of higher-order types, but these are first-order expressions, so that first- 
order matching could be used. Rollins and Wing point out that equational reasoning 

3. This name is from the Latin verb “to hunt”. 

4. For these authors, the word “signature” refers to the rank of a higher-order function, rather than 
to the syntactic specification of a software module, as in the algebraic tradition. 

5. The Venari project uses the term “partial match” in a more restricted sense than we do; their 
term corresponding to our “partial match” is “relaxed match”. 
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could dramatically increase precision, and they also discuss the possibility of 
specification matching. 

Zaremski and Wing [34] extend this work. First, they consider signatures in two 
different senses, as the rank of a function, and as the interface of a module; the second 
sense involves search and retrieval of modules, not just of functions. Second, they 
consider a wider variety of matching procedures and their combinations, although some 
of these are needed only because of the awkwardness of the higher-order encoding of 
operation ranks (e.g., uncurrying). Third, they implemented their matching procedures in 
ML, experimented with retrieving functions from actual ML libraries, and presented 
some interesting statistics on these experiments. 

In more recent work, Zaremski and Wing [35] focus on specification matching, 
using the Larch/ML interface language to express pre- and post-conditions in first order 
logic, and the Larch prover to verify that candidate components satisfy these conditions. 
Various senses of matching are defined, but neither ranking nor partial semantic 
matching are considered. This approach has not resulted in a practical automated method 
for specification based retrieval. 

E. THE CAPS APPROACH 

The CAPS project at the Naval Postgraduate School, headed by Professors Luqi 
and Valdis Berzins, supports rapid prototyping for hard real time embedded systems. 
CAPS consists of an integrated set of software tools that help design, translate and 
execute prototypes. These tools include an execution support system, a syntax directed 
graphical editor, an evolution control system, a change merge facility, automatic 
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generators for schedule and control code, and facilities to support retrieving reusable 
components from a software base. The execution support system includes dynamic and 
static schedulers, a translator, and a debugger. 

PSDL is the Prototyping Description Language of CAPS [20]; it is used to 
specify both prototypes and production software, and has data flow like semantics. 
PSDL programs have two kinds of objects, corresponding to abstract data types and 
abstract state machines; they localize the information for analyzing, executing and 
reusing independent objects. Executable Ada modules can be associated to atomic PSDL 
objects, and then CAPS can automatically generate “glue" code that composes these 
modules into a system having the structure described by PSDL. This generated code 
includes a schedule and tests for all real time constraints that have been declared. The 
system can then be compiled, executed, and tested. Error messages are produced during 
execution if constraints are violated. Figure 1 illustrates a prototyping life-cycle. It 
shows two places where component search can be used in such a life-cycle: in 
constructing a prototype system and in constructing a production system. 
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Figure 1. A Prototyping Lifecycle 


The remainder of this subsection concentrates on work done in the CAPS project 
on retrieving software components. The use of specifications in retrieving software 
components was originally suggested by Professor Luqi [19]. This suggestion was 
refined in later work, including [32] and Steigerwald's Ph.D. thesis [33]. In [33] it is 

assumed that each component has a fully expanded^ algebraic specification written in 
OBJ3 [6, 10, 16], and that the user's query is also a fully expanded algebraic 
specification that the desired component should satisfy. A Prolog program was written 
using symbolic representations of signatures to find syntactic matches between the 
signature of the query and the signatures of components. For each match found, a 
semantic validation was done by evaluating patterns that represent the functions in the 


6. This means that the results of any module expressions inside a module are substituted into the 
module. 
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signature, first in the query specification , and then (after translation) in the 
specifications of the matched components; the results of these two evaluations are 
compared to determine the quality of each match. The approach developed in this series 
of papers is the inspiration for the approach taken in the present dissertation. 

The system described in [33] has certain technical limitations. Its semantic basis 
is not well developed. Also, evaluating patterns with variables gives limited information 
about the semantic satisfaction of a syntactic match. In addition, since patterns can 
involve variables that may or may not be eliminated by rewriting, depending on syntactic 
peculiarities of the equations, it seems possible to have semantically equivalent 
specifications for which pattern evaluation would give conflicting answers, so that the 
match in question will appear not to satisfy its semantic requirements even though it 
really does. In addition, the approach is limited to total syntactic matches and to 
unparameterized components. 

Ozdemir's master's thesis [28] describes a component retrieval system for the 
CAPS software base that uses keyword search and a browser. Both of these use PSDL 
for queries and for components. Ozdemir also provides a graphical user interface and 
facilities for integrating retrieved components into prototype systems, including 
techniques for transforming retrieved modules. A better developed version of these ideas 
appears in the master’s thesis of DolgofF [2]. This work is including retrieval of generic 
modules and handling of subsort matching. 

7. These patterns are terms that involve those functions, plus some variables, constants, and con¬ 
structors, such that all other functional expressions are instances. 


11 



F. DISCUSSION 


In comparing the approach of this dissertation with other approaches, the 
following points may be noted: (1) Our approach focuses on comparing formal 
specifications of components using ground equation test cases as queries. (2) Users do 
not need to deal with formal specification notation, but instead can express queries in a 
standard programming notation, which is automatically translated into algebraic 
notation. (3) We seek to achieve both efficiency and effectiveness by imposing a series 
of increasingly stringent filters that use both syntactic and partial semantic information 
about components. (4) A rank is provided on components in the choice set, measuring 
how well they fit the user's query. (5) We allow generic modules in the software base. 
(6) Our approach not only focuses on the problem of retrieving components, but also 
deals with structuring the software base to facilitate search. (7) Users can give selection 
criteria to control the search and display of retrieved components. (8) Besides returning 
the ranked components, we also report information to help the user reformulate the query 
in case no suitable component was found. (See Figure 2 in Chapter III) 
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III. ARCHITECTURE OF THE SEARCH PROCESS 


This dissertation proposes an approach to the automated retrieval of reusable 
software components from a software base, continuing work reported in [14, 19, 21, 32, 
33, 7], The approach is based on the following assumptions: (1) the components in the 
software base are written in a modem programming language, e.g., Ada, that has strong 
typing, can package together a number of operations over common data representations, 
and allows generic modules having a number of parameter types and operations; (2) each 

component has an algebraic specification* with equations that are Church-Rosser and 

terminating^; and (3) the user's query is a partial algebraic specification, typically 
consisting of a signature and some ground equations. Assumption (2) is not really 
limiting, because specifications need not completely characterize the behavior of 
components, and simple partial specifications are usually Church-Rosser and 

terminating*®. Similarly, assumption (3) is not limiting, because there is no need for 
users to be familiar with algebraic specification: query signatures can be expressed as 
declarations in some familiar programming or specification notation, and the query can 
be described in terms of the results of executing simple programs. Note that the software 
base may contain generic modules, and queries may seek to identify a generic module 
having certain semantic properties. 


8. [26] describes an approach where components do not need associated algebraic specifications. 

9. These terms are explained in Appendix A. 

10. Note that any set of ground equations with distinct irreducible left sides is automatically 
Church-Rosser and terminating. 
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In our approach, search is organized as a series of increasingly stringent filters on 
candidate components. We first filter components by comparing their signatures with 
that of the query. This is accomplished by signature matching, which looks for maps that 
translate the type and function symbols of the query into corresponding type and 
function symbols of candidate components. A first stage of signature filtering can 
compare pre-computed syntactic profiles of components with the profile of the query. 
These profiles are special data structures that support an efficient approximation of 
signature matching. Signature matches can be partial, in that only part of the 
functionality the user seeks may actually be available. Traditional search methods, such 
as keyword search, could also be used as eariy filters, if the appropriate information is 

available'^ Profile matching should be followed by full signature matching. 

Finally, semantic filters rank components by how well they satisfy the equations 
in the query. In this process, equations that are logical consequences of the query 
specification are translated through the signature matches into equations whose proof is 
attempted in the candidate specifications. For greatest efficiency, it is desirable to restrict 
queries to be ground equations; these correspond to simple straight line programs. The 
candidates in the choice set are ranked according to their likelihood of success. If the 
closest match is partial, the user will need to modify the closest matching component. 
This whole process can be made iterative. 


11. The precision difficulty with keyword search mentioned in Chapter II. 1 does not apply in this 
case, because we are only using it as a filter to reduce the search space. 
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Our present knowledge indicates that profile and keyword filtering should be 
applied first in order to eliminate as many components as possible with the lowest 
possible cost. Therefore syntactic filtering, and keyword filtering, should come before 
any semantic filtering is attempted. It is also clear that pre-computed catalogues (i.e., 
indexes) should be used, instead of pulling all the components out of the library for each 
search. The experiment E in Chapter VIII confirms this conjecture. Figure 2 shows this 
multi-level filtering architecture; the top line is to indicate user modification of the query 
in light of the final filtering results. 



Syntactic Semantic 

Matching Matching 


Figure 2. An Organization Model for Software Component Search 
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IV. SYNTACTIC FILTERING 

Syntactic filtering uses non-behavioral information about components, such as 
keywords and interface declarations. Our approach involves two levels of syntactic 
filtering. First, profile filtering computes indexes which partitions the software library in 
a way that speeds up signature matching. These partitions contain the candidate 
components. Next, a Profile and Keyword Matching Ratio values are computed for each 

candidate component. These values will be then combined*^ with this component 
Signature Matching Ratio, computed by the signature matching next, to prune 
components which do not meet the user selection criteria. Secondly, signature matching 
finds the maps that translate the type and function symbols of the query into the 
corresponding type and function symbols of the candidate components. 

A. KEYWORD MATCHING 

Despite its weaknesses, keyword search is still useful, because it is easy to use, 
inexpensive to implement, and good for indexing components. However, we use 
keyword filtering cautiously, with a limited number of general keywords that are 
controlled by a system administrator. Keywords describe categories of components and 
their relationships to the other components. Sample categories might be data structures, 
mathematical functions, soit/search routines, and navigation functions. 

We use the following function to measure how close the keywords of a queiy, 
Kwq, are to the keywords of a component, Kwj^. 

12. This combined value is referred as KPS which stands for the product of Keyword, Profile, and 
Signature matching ratio. Chapter VI formally defines the KPS. 
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KeywordMatchRatio(KwQ, Kwj^^ = \K'^q KwJ^/\Kw^ . 

Note that this function measures recall. The numerator represents the number of 
relevant retrieved keywords while the denominator represents the total number of 
relevant keywords in a query. 

B. SIGNATURE MATCHING 

This subsection introduces and illustrates the basic concepts of signature 
matching, under the assumption that there are no subsort'^ relations; the more complex 
situation when S has subsorts (i.e., a partial order containment relation < on data 

types) is discussed in Sections IV.3 and IV.4 below. We assume'"* that each component 
M in the library has an associated algebraic specification of the form {S’, Z', E\ 

where {S\ £') is a signature with a set S’ of sorts and a set E' of functions whose 
arguments and results have sorts in S’, and where is a set of equations stating 
properties that the functions in E' should satisfy. We also assume that query, Q, is an 
algebraic specification of the form {S, E , £) where these symbols mean the same as T^. 
The following illustrates these notions, using the notation of OBJ3; definitions for 
signature, specification, etc., can be found in Appendix A. 

Example 1 The algebraic specification for a module defining list of identifiers in 
our library might have a sort set S containing the sorts Id, List, and Bool, and a signature 


13. Note that algebraic specification theory and OBJ3 use the world “sort” instead of the word 
“type”. 

14. We will see how to relax this assumption later. 
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S of functions consisting of the empty list, denoted nill, an append operation *, and a 

function to test whether an element is in the list, with the following syntax: 

sorts Id Bool List 
op nill : -> List. 
op : W List -> List. 
op _in_: Id List -> Bool . 

The equations in the specification might be: 

I in nil = false . 

I in (r * L) = if (I == I') then true else I in L fi. 

We also assume that: the library has a set of basic sorts for commonly used 

types like Booleans, identifiers, integers, and floating point numbers; that the names of 

these basic types and their associated basic operations are identical in the specifications 

and in the code; and that the library modules and the algebraic specifications for the 

basic types also have the same names. 

Definition 1 Given two signatures (S, E) and (S', E '), a permutative signature 
map V: (5,E) (S\Z ') consists of injective functions V: S S’ and V: E -> E' such 
that for each function symbol f : sj...s„ 5 in E, there is a permutation n such that 

^(f) ^(“^ 71 ( 1 )) ->■ V(s) is a function symbol in E'. A partial 

signature match V: (5,E) —>■ (S',!.’) is a permutative signature map 
V: (S^, E^ ) (S',E') where (S^, !J is a subsignature of (S, E) ; it is total if 

(5„E^) = (5,E). 


15. This dissertation will use the words “sort” and “type” interchangeably, and will also use the 
words “function” and “operation” interchangeably. 
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The assumption that V is injective on both sorts and operations is reasonable if 
there is no subsort relations, because otherwise the user would be asking for two or more 
things that are not actually different. 

Definition 2 Given a library and a query Q = (S,'L,E) , the signature choice 
set for Q consists of all signature matches V: (S, S) -> (S', Z') where 

= (S', Z', E') is the specification of some component M, and where each match V 

is the identity mapping when restriction to the set of basic types and their basic function 
symbols. Note that the semantic information in the equations is ignored in syntactic 
matching. To simplify notation and make explicit the module specification associated 
with a signature match, we may write V Q-^T^^ for a signature match 

V: (S, Z) (S', Z') such that = (S', Z',£') is the specification of a component 
M 

The more complex situation when S has subsorts (i.e., a partial order relation < ) 
is discussed in Sections rv.3 and IV.4 below. 

Example 2 Assume that a user wants to find a module for sets of identifiers, 
where the sort Id of identifiers and the sort Bool of Booleans are basic sorts. Suppose 
that the signature for such a query includes an empty set, functions for adding and 
deleting an identifier from a set, and a function to test whether a given identifier is in the 
set. This can be expressed in OBJ3 notation as follows; 
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sorts Id Bool Set. 
op null; -> Set. 
op _+_: Set Id -> Set. 
op . Set Id -> Set, 
op Jn_ : Id Set -> Bool. 

(Note that the “underscore” characters are place holders, indicating where the 
arguments should go in "mixfix" functions.) 

Suppose that the library, among other things, contains a list of identifiers module 
whose specification has the signature shown in Example 1. The set of all signature 
matches from the query to this module has 17 elements. The least defined element Fy is 
the identity map on Id and Bool and is undefined elsewhere. V 2 extends Vj by mapping 
Set to List. The maps V^-Vg each extend V 2 by respectively sending null to nil, sending 
_+_ to sending to and sending _in_ to _in_. The rest are obtained as unions 
of V^-Vg satisfying the requirement of being injective, as follows: 

. v, = v,^v,- 

• ^ 12 = 

• ^13 = 
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Our intuitive knowledge of the behavior of sets and lists tells us that the best possible 
match is Vl2- 

For the illustration purpose, a Hasse diagram for the signature maps refinement 
relation c is shown next page: 



Figure 3. A Hasse Diagram for the Signature Map Refinement Relation c 
Note that only the maximal elements V |2 and V 13 in this partial ordering are 
interest - all the others will be strictly less useful. This provides a pruning criterion for 
signature matching. 

C. PROFILE MATCHING 

The computations for signature matching would be very expensive if it were 
necessary to try all possible ways of pairing the functions and sorts of queries with those 
of components. It is therefore highly desirable to cut down the search space. This can be 
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done. For example, if a query has a function f. AAB-^B and a component has a 
function g: ABC-^D, then it is obvious that these functions cannot match, because 
their arguments have different sort patterns; there is no need to compute all possible sort 
maps to draw this conclusion. 

The purpose of profile matching is to speed up signature matching. Profile 
matching is actually an efficient approximation of signature matching. A profile is a 
sequence of numbers that describes how the sorts associated with an operation are 
organized. We can quickly determine whether two given operations could possibly 
match by comparing their profiles, and hence quickly identify query operations and test 
cases that will necessarily fail. Profile matching uses pre-computed profile indexes to 
partition the library, and profile values are used as search keys in seeking components 
having suitable signatures. 

We now introduce some concepts to help us define profiles. The sort groups of 
an operation are bags (i.e., multisets) consisting of two or more sort occurrences from the 
rank (i.e., the argument plus value sorts) of the operation that are related under the 
relation =, which is the transitive-symmetric closure of the ordering < on sorts. The 
unrelated sort group is the bag (actually a set) of all sort occurrences that are not in any 
sort group. 

Definition 4 The profile of an operation is a sequence of integers, defined as 
follows: 

1. The first integer is the total number of occurrences of sorts. 

2. If the total number of sort groups, N, is greater than 0, then the second to 
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(1 + integers are the cardinalities of the sort groups, in descending order. 

3. The {1 + N)‘^ integer is the cardinality of the unrelated sort group. 

4. The (3 + AO integer is: 

0 if the value sort is different from any of the argument sorts; and 
1 if the value sort belongs to some sort group. 

A signature map can relate two operations only if they have the same profile (i.e., 

the same number of sort occurrences, the same number of sort groups, the same sort 

group cardinalities, and the same unrelated sort group cardinality). 

Example 3 Some sample profiles are shown in Table 1, where A, A\ B, C, E, F, 

G are sorts, and is a subsort of A: 


Operation 

Profile 

-^A 

no 

EF^G 

330 

AA->B 

3210 

ABBCA ^ C 

622201 

CCBAA -^B 

622201 

CCBAA -^A 

63211 

CCBAAA’^A 

724211 


Table 1: Some Operations and their Profiles 


We are now ready to introduce a theorem which is very useful for the structuring 
the software library, retrieving candidate components, and performing signature matching. 
This theorem is stated below and verified through the Experiment C in Chapter VIII. The 
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formal proof is also provided in Appendix E. Appendix E also shows = as an equiva¬ 
lence relation. 

Theorem 1 Given a query operation and a component operation with their corre¬ 
spond profile values, if these profile values are not equal, then these operations can not be 
possibly matched. 

1. Software Base Partitioning with Profiles 

Each component C in the software base, L, has an implementation part and a 
specification part. The implementation part is implementation language source code, 
while the specification part is written in the CAPS prototyping language PSDL with 
embedded OBJ3 axioms. For each component C, let b(C) denote the multiset of profiles 
of all operations that occur in the signature of C; this information may be extracted either 
from the source code of C, or from the PSDL or OBJ3 specification of C, and is called 
the profile of C. 

If 5 is a multiset of profiles, let P(5) denote the set of all components C in the 
software base L such that the profile value of C is S, i.e., let 

P{S)= {C e L|5’ = b{C)} 

Let P be the set of all profiles that occur in the software base, and let 11 denote 
the set of all subsets S ofP such that P(5) is non-empty. Then 11 is a partially ordered set 
under set inclusion, and it induces a partition for the set of components in the software 
base, n can be represented graphically as a so-called Basse diagram, having as its 
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nodes the elements of II, with an edge upward from to S 2 iff c and there is 


no node such that 5 , a <z 82- 

Given a profile p in P, we define the frequency of p to be the number of profiles 
5 in n that contain p, i.e., 

Freq{p)=\{ SgR |/i e 5}| 

Let us call sets S’ such that l-S”! = 1 bottom nodes, and define H ’ to be 11 plus 
all bottom nodes S’ not already in n, again ordered by set inclusion. This is the structure 
actually used in the implementation. Note that we can still talk about the frequency of 
profiles in n and that Freqip) can be computed by recursively following edges upward 
in the Basse diagram, starting from the bottom node {/?}. 

Example 4 To illustrate the above concepts, assume a small software base such 

that: 


b{C\) = b{C2) = b{C3) = {p^P2} • 

b(C4) = biC5) = {p^P2,P^. 

b(C6) = b{Cl) = b{C%) = {PfP2,P4,P^ , 

b(C9) = biClO) = {p^,Ps), 

biCll) = b(Cl2) = biCU) = {p^,P2P3,P4^ , 

biCl4) = b{Cl5) = {p^,P2P4,P^- 

Then 

P = {PvP2P3>P4^P5’P^ - 
and if we assume 

*^ 1 = {PvPl^ . -^ 2 = {P^Pi^P^ > ^3= {Pi,P2^P4^P^ . *^ 4 = {P^P^ - 


26 



■Ss' \PtP2’PyPi ■ ■%= {PfPi.Pa.P^ . 

y, - (;>,},yj= {/>,}, ^3= (/>3),y4 = {Pi),s',= (P5},y6= ip^i 
then we have that 


n = {s^s,,s^,s,,s^,s^ . 

n' = {s\,s\,s’„s\,s’„s\,s,,s^,s„s„s,s^ . 


and also that 

P{S,) = {Cl,aC3}.P(52) = (C4C5). 
^(^ 3 ) = {C6,C7,C8}. ^(.^ 4 ) = {C9,C10}. 
P{S^) = {CWXMCU} ,P{S^) = {C15,C16}. 

Let us also assume that 

Keywords = {A,B,C,D) , 

Kw{C\) = ... = /:m^(C5) = {AB} , 

Kw{C6) = ... = Kw{C\0) = {BQ, 

Kw{C\0) = ... = .^:w(Cl5) = {QD} . 

Figure 4 shows the software base partition for this data. 


P(S5)= P(S6)= P(S3) = 

{C11,C12,C13) {C14,C15} {C6,C7,C8} 



Freq(l) = 6 Freq(2) = 6 Freq(3) = 3 Freq(4) = 5 Freq(5) = 3 Freq(6) = 6 
Figure 4: A Software Base Partition 
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In our implementation, each block of the partition is described as a set of pointers 
to indexes in the ComponentLookupTable, which has a cell for each component, 
containing the keywords for the component, and a pointer to physical disk location of the 


component. These pointers are called CompomntIDs. Finally, the software base keeps a 
separate keyword table for storing keyword identifications (KeywordIDs), called the 
KeywordTable. Figure 5 shows the software base index structure for the data in Example 


4. 



A 

B 

C 

D 


Figure 5: A Software Base Index Structure 


Keyword id 1 
Keyword id 2 
Keyword id 3 
Keyword id 4 
KeywordTable 
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There are two important data that reside on the physical disk. First, the data used 
for matching. Second, the data used for importation to a user’s prototype. The data used 
for matching are specified by item (a) and (b) below. Once a component is selected by 
the user, the data used for importation to user’s prototype is specified by item (a), (c), 
and (d). Therefore, we organize the physical file representation of a software base 
component as follows; 

a. A file containing a PSDL specification, for the translation and scheduling for a 
prototype using the component. 

b. A file containing a OBJ3 specification, used for both signature and semantic 
matching. 

c. A file containing an Ada specification, which is imported to become an atomic 
operator's Ada specification in a prototype, after some modifications. 

d. A file containing an Ada body, corresponding to the semantic part. It is 
imported to a prototype, to become an atomic operator's Ada body, after some 
modifications. 

This organization supports traditional graph search algorithms, such as depth first 
search, to implement DBMS operations such as initialize, delete, add, and retrieve. There 
could also be a file for compiled code, which could replace the use of OBJ3 for some 
queries. 

Given a query profile Sq and component profile S^, we define the ratio 

ProfileMatchRatio to measure how close the query profile is to the component profile as 
follows: 

ProfileMatchRatio {Sq,S(^) = . 
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This is again a recall measure. The numerator represents the number of relevant 
retrieved profiles while the denominator represents the total number of relevant profiles 
in a query. 

2. Retrieving Components with Profile Matching 

The following algorithms find the candidate components in a software library: 
Algorithm 8 FindCandidateComponents 

Input: 


Q = (S,I,E)- 

Kwq = {Queiy Keyword Ids}. 

G = (P,R) whereP = (Partitions} andR = (Inclusive relations}. 
ComponentLookupTable = Array of 2-field records; Component Keywords and 
Component Pointer. 

Output: 

CandidateTable = Array of 3-field records; Component Id, Keyword Matching 
Ratio, and Profile Matching Ratio. 

Invalid Operations = (Invalid Operations} 

(1) Compute profile value, p, for each operation in Q.I.. 

(2) For each profile p, verify against the bottom nodes in G. If Freq(p) =0, then 
store p in Invalid Operations. 

(3) For each ground equation i in Q.E, identify its associated profiles using the 
correspond operation’s profile values found in step (1). Store these associated 
profiles in a variable called G/7,.(Note: Gpj is a multiset). After that store each 

of Gpj into Gp. 

(4) Let N be the set of starting nodes contains every node indexed by profile 
multi-set of size one that is included in the query profile. 

(5) For each n in N, call DepthFirstSearchForward. 

(6) Report invalid operation(s) in Invalid Operations. 
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Algorithm 9 DepthFirstSearchForward 

Input: 

G = (P,R) whereP = {Partitions} and R = (Inclusive relations}. 

V = An element of P. 

CandidateTable = Array of 3-field records: Component Id, Keyword Matching 
Ratio, and Profile Matching Ratio. 

Gp = (GpjS, where Gp^ is a multiset of profile in a ground equation i in Q.E} 
ComponentLookupTable = Array of 2-field records: Component Keywords and 
Component Pointer. 

Output: 

CandidateTable = Array of 3-field records: Component Id, Keyword Matching 
Ratio, and Profile Matching Ratio. 

(1) Mark v visited. Assign with Partition v’s profile values. 

(2) For each G/?, in Gp, If Gpj c Py then 

Calculate the Profile Match Ratio. 

For each component pointer at node v do 

Index to an element in ComponentLookupTable. 

Calculate the Keyword Match Ratio. 

Store Profile and Keyword Match Ratios and 
ComponentID in CandidateTable. 

(3) For each vertex n adjacent and above v do 

If n not visited then DepthFirstSearchForward. 

D. SIGNATURE MATCfflNG ALGORITHM 

The signature matching algorithms seek to find good partial signature maps V: 

iSX) —>• (S',Z'), where (S,E) is the signature of the query Q and (S\L') is the signature 
of a component M. Recall that the basic sorts are those common to all modules. The 
algorithms below take advantage of the following requirements for a signature map F, 
with sort map : S—> S’ and operation map F^,: E —> E' : 
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1. Vg must be injective. 

2. Fj must preserve the subsort relation, i.e., s■^ < ^2 in 5" implies 
F(5 j) <V(s 2 ) in 5’. 

3. Vg must preserve basic sorts. 

4. must be injective. 

5. must preserve basic operations. 

6. The profile of each operation / in 1, must be the same as the profile of (/) 
in r. 

7. If an operation / in S has argument sorts 5j,..., 5^, and if in 2' has 
arg;ument sorts 5 ',, s’^, then there must be a permutation n of {such 
that F(5^(.)) = 5 '. for/ = 1,and such that V(s) =s'. 

This generalizes Definition 2 to the case where there are subsorts. Dolgoff [2] 

made some initial studies of signature matching with subsorts. 

Given a signature match V, the measure of how close the signature of the query Q 

is to a component signature is given by the following: 

SignatureMatchingRatio(V,Q) = iV.'Ll/lQ.'Ll, 

where Q.I, is the signature of the query and V.H is the subsignature of Q.I> that is 

actually matched by V. 

The following three algorithms provide the method for signature matching. The 
algorithm SignatureMatch computes V^, CalculateSortAssignment computes V^, and 

SortAssignable determines whether a sort assignment can be made. 

Algorithm 10 SignatureMatch 
Input: 

Query signature, (S,2). 

Component signature, (S’,2’). 
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Output: 


Signature maps, V = { Signature Maps }. 

where Signature map = ({Sort Maps), {Op Maps}) 

Sort Map = (s s’), s in S and s’ in S’ 

and Op Map = (op —> op’), op in Land op’in S’. 

Variables; 

Stack is a FIFO stack for storing/retrieving 0. 
i, j are indexes to query and component operations. 

Temp Sort Map is a temporary Sort Map 

(1) SetV={}. 

Initialize state variable 0 = (Sort Maps,Op Maps, Operation Mark List = {}, and 
Operation Occupied List = {Falses}. Set i = 1, m = 1 . 

( 2 ) While True do: 

j = find_an_available_component_index(i,Operation Occupied List, 
Operation Mark List). 

If j = Invalid and i /= Invalid then 

If i = I L I then -- Both i and j are finished 
If Stack is Empty then 
Exit; 

Else 

If (Sort Maps,Op Maps) is not a submap in V and preserve 
subsort relation then 

V = V (Sort Maps,Op Maps). 

0 = Pop(Stack). 

End If 
Else 

Clear_all_previous_visit_operations(i,Operation Occupied 
List,Operation Mark List). 
i = i + l; 

End If 

Else --j is not finished 

Operation Occupied List(j) = True; Operation Mark List(j) = i. 

If Profile(i) = Profile(j) then — If their profile are the same 
Clear_previous_visit_operation(i,j,Operation Occupied List, 
Operation Mark List); 

Calculate_Sort_Assignments(Argument_Sorts(i),Argument_Sort(j) 
, Range_Sort(i), Range_Sort(j), Sort Assign Table, Map Num). 

If Map_Num > 0 Then ~ There is possible sort maps 
Push(0, Stack); 
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Op Maps = Op Maps (Symbol(i) -> Syinbol(j)). 

For n = 1 to Map Num do - Save all possible maps on Stack 
Temp Sort Maps = Sort Maps. 

Sort Maps = Sort Maps u (Sort Assign Table(n)). 

Update 0 and Push(0,Stack. — Save on Stack 
Sort Maps = Temp Sort Maps. 

0 = Pop(Stack); -- Now get one 
Ifi < 111 then 
i == i + 1. 

Else -- Keep i constant 

If (Sort Maps,Op Maps) is not a submap in V and preserve 
subsort relation then 

V = V u (Sort Maps,Op Maps). 

0 = Pop(Stack). 

End If 
End If 
End If 
End If 

In discussing the algorithms below, we will use the following terminology; A 

non-basic sort of the component is confined if it is the image of some sort of the query 

under V, or is related to a confined sort under s ; a non-basic sort that is not confined is 

called unconfined. Two sorts s, s' that are not related under V are called unrelated, 

written s not = s'. These algorithms try to map unassigned sorts to appropriate values, 

and to assign appropriate values to the parameters of generic components. 

Algorithm 11 Calculate_Sort_Assignments 
Inputs: 

Sj is the argument sort set of the query operator. 

S'j is the argument sort set of a component operator. 
s^ is the value sort of a query operator. 

5 ^, is the value sort of a component operator. 

Sort Maps = {Sort Maps}, current sort maps. 

Sort Map = (s —> s’), s in S and s’ in S’ 
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Output: 


Sort Maps’ = (Sort Maps}. 

Variables: 

Temp Sort Maps is temporary Sort Maps. 

SVL is the sort visiting list, for storing pairs of indexes of element in Sj 
and S'j. 

ij are the indexes to argument sort of Sj, S'j. 

Pj, is the previous j index that is being occupied by i. 

Lds is a list of flags indicating whether argument sorts in S'j are 
occupied or not. 

3 is state variable consists of TempSortMaps , SVL , j, Lds. 

(1) Initialize P with TempSortMaps <- SortMaps ; SVL , Lds <- Null', / <- 1. 
Initialize Lds <- Falses, SAL <- Null . 

(2) If Sort assignable(Sort(5^) ,Sort( s'^)) then 

TempSortMaps TempSortMaps ( 5 ^, s'^ . 

Otherwise, return 

(3) Find j such that Lds. ^ True and SVL^ ^ i. Find a p., such that SVL = /. 

J J J Pj 

(4) If / = Invalid, then check the Stack. 

If it is Null, then return 

Otherwise, P <— pop {Stack) . Return to step (3). 

(5) Otherwise, if p.,:^ Invalid, then Lds <-False . 

J Pf 

LdSj <- True ,SVLj / 

(6) If Sort_assignable(sort(i),sort(j)), then Stack <- push (P^., Stack) . 

TempSortMaps <-TempSortMaps u (sort(i), sort(j)). i=i + l. 

If /■ > [51 then 

SortMaps’ SortMaps’ u TempSortMaps , p <r- pop {Stack) . 

(7) Return to step 3. 
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Algorithm 12 SortAssignable 


Input: 

is a query sort, 
is a component sort. 

Output: 

Aflag is a Boolean, true if and only if an assignment can be made. 

(1) Determine the sort relation between and by consulting a row of Table 2. 

(2) Determine the sort type of q^ and by consulting a column of Table 2. 

(3) Look up the result in Table 2 and assign that value to Aflag 

(4) If Aflag is True then 

Aflag is True 
Else 

Aflag is False 

(5) Return Aflag 



III 

'S 


Basic — > Confined 

F 

T 

Basic — > Unconfined 

T 

N/A 

Basic -> Basic 

F 

T 

Confined -> Basic 

F 

T 

Confined Unconfined 

F 

N/A 

Confined Confined 

F 

T 

Unconfined —> Basic 

T 

N/A 

Unconfined —> Confined 

F 

N/A 

Unconfined -> Unconfined 

T 

N/A 


Table 2: Sort Assignments Table 
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V. SEMANTIC FILTERING 

The choice set of signature matches for a query can be further narrowed by seman¬ 
tic filtering. Under certain very reasonable assumptions, this can be done efficiently by 
checking satisfaction of certain semantic conditions that are necessary for any correct 
answer to the query. 

We discuss only unparameterized specifications here. In addition, we assume 
throughout that the specifications associated with components have equations that are 
Church-Rosser and terminating. This means we can apply the equations from left to right 
to simplify a term to a unique simplest possible form, called its canonical form, which can 
be regarded as the result of evaluating the term. For example, the canonical form of the 
term. 

a in (b * (a * nil)) 

using the equations in Example 1 is true. 

Our semantic validation procedure takes ground equations t=t' from the query 
specification Q and tests them for satisfaction in the candidate specifications. Ground 
equations, that is, equations whose terms have no variables, are particularly useful here, 
because any ground equation provable from an equational theory Q is satisfied by the 
standard model of such a theory, i.e., the initial algebra Tq of Q, so that those equations 
are also satisfied under the initial (standard) interpretation of Q. 

This is important because either the query Q or the component specifications Tj^ 
may have an initial interpretation, so that proving the semantic correctness of a signature 


37 



match F: Q -> 7^^ could require complex theorem proving to check inductive 

consequences. A special property of ground equations is that their translations V(t) = 
V(t') must be provable from in order for V to be correct, regardless of whether Q and 

are interpreted initially or loosely. Therefore, we can use them under either 

interpretation to further restrict the search for correct answers to the query Q. The great 
advantage of ground equation is that we can automatically settle the issue of whether 
V(t) = Vfi') is provable from by comparing the irreducible forms of V(t) and V(0 

after rewriting them with the equations in since Tm is assumed to be Church-Rosser 

and terminating. This results in an efficient decision procedure for behavior queries 
expressed in this form. 

The next subsection explains how to rank members of the choice set based on 
semantic filtering. 

A. ORDERING SEMANTIC MATCHES 

Since many signature matches for a query might be found in a large library, it is 
important to narrow the search by using whatever semantic information is available at 
each filtering stage, either from the specification Tj^, the compiled component A/, or 

both. For this, a sound way of ordering the matches according to their relative degree of 
semantic correctness is needed. We define below two measures that can be used for this 
purpose. These measures assign a value to each pair (V,Iy) consisting of a signature 

match V for the query Q, and whatever information ly is available at that stage about 
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equations that have passed or failed the semantic checks. Such measures can be used 
independently or in combination to define choice sets. 

Given a match V, the information ly available for it may be either syntactic or 

semantic. Syntactic information will include the functions in the query's signature for 
which the match is defined and their translation under such a match. Semantic 
information will include the results of checking correctness of ground equations after 
translating them through V. For each such ground equation and match V three things can 
happen; 

• The translated equation is well defined and, after reducing each side to normal 
form using the equations in the specification of the module matched by V, 
yields an identity, therefore this equation has succeeded for this match; 

• The translated equation is well defined and, after reducing each side to normal 
form using the equations in the specification of the module matched by V, 
yields an equation whose two sides are different; therefore this equation has 
failed for this match; 

• The equation could not be translated, because the match V was undefined for 
some of the functions appearing in the terms of the equation; this is also a kind 
of failure. 

Note that we can associate each equation with a function symbol, namely the top 
function symbol of its left side. Therefore, we can assume that the semantic information in 
ly is organized by function symbol so that for each such symbol / in the query's signature 

we have a set of ground equations for it, and information about their success or failure for 
the match V. 
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The first measure |i assigns to each pair (FJy) a real-valued function 


Q -> 9?, where £1 is the signature of the query Q, defined as follows; 

• If F(/) is undefined, then 4 (k,/)(/)“ ® 

• F(/) is defined but has no ground equations associated with it, then 

Success ( f\ 

• Otherwise, \i^yj y = , where success (/) is the number of suc¬ 

cessful checks for ground equations t = i' with t having / as its top function 
symbol reported in ly. Equations (/) is the total number of such equations. 


Consider now two different matches V and V' for the same query Q, and suppose 
that the same ground equations from Q have been tried for V and for V'. Then we can 
compare the degree of success of these matches on an operation by operation basis. If for 
each operation symbol f we have (/) ^ F is an altogether better 


match than F’. The ideal situation is of course when we find a match that is better than 
all other matches in exactly this sense. However, such an absolutely better match may 
not exist in the library and we may only get matches that are maximal in their degree of 
success, that is, no other match is better than them for all functions. This can happen 
when a query is large enough that two or more parts of the required functionality are 
available, but their combination is not. In such a case we will find several maximal 
signature matches that are each best for some fragment of the functionality, but are 
incomparable among themselves under the p ordering. An appropriate environment 
could use this information to help the user synthesize an optimal combined component 
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out of actual components whose corresponding signature matches have maximal p- 
measures. 

The second measure SemanticMatchRatio is cruder. It is obtained from the first 
by assigning to each pair (F,/^) a real number defined by the equation: 


SemanticMatchRatio{V,Iy) = X ) (/) ’ 

/e Q 


where Q is the signature of the query Q. 

Once we obtain a SemanticMatchRatio of a component, we can compute the 
overall ComponentRank. Since Semantic Matching Ratio is the most significant 
information and derivable from Profile Matching and Signature Matching, it is important 
that we order the component base on this. Keyword Match Ratio is the second important 
piece of information due to how well a user can specify the keywords. The 
ComponentRank is then a 2-tuple of matching ratios with lexicographic ordering and is 
defined as follows; 

• A component which has a higher SemanticMatchRatio is ordered first. Compo¬ 
nentRank would be included its SemanticMatchRatio and KeywordMatchRa- 
tio. 

• Any components which have the same SemanticMatchRatios, then a compo¬ 
nent with a higher KeywordMatchRatio will be used to order the components. 
Again ComponentRank would be included its SemanticMatchRatio and Key¬ 
wordMatchRatio. 
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VI. IMPLEMENTATION 


A. CHOICE OF LANGUAGES AND SUPPORT SYSTEMS 

This chapter describes the implementation of the Architectural Model for Software 
Component Search. The prototype of this model is written in Ada programming language. 
The whole program is about 3280 lines of code. With the intention to improve and port 
this prototype to the CAPS environment for usage, the author chooses Ada as the primary 
implementation language. In the future, this work will be also integrated with [36]. This 
work would include an Ontos data base for storage and retrieval of software components. 
These data base functions will be written in C-h- with Ada bindings to enable them to be 
used from an Ada main program. All components specifications in the software base are 
written in the OBJ3 language. All of these processes are executed by a main module called 
Software Component Search (or SCS). The implementation of each of these processes is 
described in the coming sections. The component OBJ3 specifications are provided in 
Appendix B. The Ada source codes are provided in Appendix C. The Unix utilities files to 
executive OBJ3 environment and support the compile/build of the SCS are provided in 
Appendix D. Figure 6 next page provides a data flow diagram of the SCS model. 
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Figure 6. An Architectural Model for Sofware Component Search 

B. QUERY SUBMISSION AND PROFILE GENERATION 

Figure 7 (next page) shows the high level structure of Query Submission and Pro¬ 
file Generation processes. These two processes are implemented by an Ada module called 
GetQuery. This module is executed first by the SCS. It reads in a user’s query specifica¬ 
tion which consists of a partial specification, keywords, and selection criterion. This par¬ 
tial specification consists of the signature and ground equations. The keywords specify a 
search path where a user thinks the desired components resided. Finally, a selection crite¬ 
rion is the is the preference conditions imposed by a user to allow a user to control the 


search process. 




Figure 7. Structure of the Query Submission and Profile Generation 

There are two variables. The first one is the product of Keyword, Profile, and Sig¬ 
nature Match Ratios (or KPS) which is defined as follows. 

KPS = KeywordMatchRatio x ProfileMatchRatio x SignatureMatchRatio 

The purpose of using this KPS value is to allow a user to zoom in a particular range 
of components which has a particular range of a retrieval syntactic rank’s values. This is 
useful when the number of candidate components is very large. The second one is the 
block of signature maps that a user is interested in to retrieve. For the current implementa¬ 
tion, each block consists of 85 maps. Since the number of maps generated by the Signa- 
tureMatch per query can be large, the program needs to establish the map collection points 
(start and stop points) so that no memory constraint exception would be raised. In this dis¬ 
sertation we refer this as a Mapping Block Number (MBN). 

Together, these inputs represent the what (specification), where (keywords), and 
how (selection criteria) questions for a query. 
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C. RETRIEVAL OF CANDIDATE SOFTWARE COMPONENTS 


Figure 8 shows the high level structure of Retrieval Of Candidate Software Com¬ 
ponents process. This process is implemented through FindCandidateComponents, Intial- 
izeSwb, UpdateCandidateTable, LookupBlocklndex, DetermineProfilelntersection, 
DepthFirstSearchForward, and InitComponentData. 


FindCandidate¬ 
Components 
(Algorism 8) 



DepthFirst| 
Search 
Forward 


Update 
I Candidate-1 
Table 


Calculate-! 

Kw/Prf- 

Rank 


Lookup¬ 

Block¬ 

lndex 


[Determine- 

Profileln- 

tersection 


InitComp- 

nentData 


Figure 8. Structure of the Retrieval of Candidate Software Components 

FindCandidateComponents is the main component of the retrieval of candidate 
software components. It executes the rest of the modules below it. DepthFirstSearchFor¬ 
ward performs a depth-first search on the Hasse diagram to find any whose profiles cover 
the set of profiles of operation in a ground equation in the query. The module Deter¬ 
mineProfilelntersection determines this condition. If any block satisfies this condition, 
UpdateCandidateTable is called to include the components of the identified block in a 
buffer containing the output, called CandidateTable. CalculateKw/Prf-Rank computes 
KeywordRank and ProfileRank for each CandidateComponent. Finally, InitComponent- 








Data sets up a CandidateComponent specification for signature-matching against the user 
query’s specification. 

D. SIGNATURE MATCfflNG 

Figure 9 shows the high level structure of Signature Matching process. It is imple¬ 
mented by SignatureMatch, FindCompOpIdx, VerifyUpdateRank, ResetPreviousVisit, 
SortAssignment, Push/Pop Stack operations, UpdateOal modules. 



Figure 9. Structure of the Signature Matching 

SignatureMatch is the main executive. It controls all the modules below it. Find¬ 
CompOpIdx finds an index which points to an available component operation so that its 
profile can be compared against a query profile. Before storing a signature map into a 
buffer, VerifyUpdateRank verifies the following conditions prior to storing a map into the 
SignatureMapTable. They are as follows: 

• A Signature map must not be duplicated. 

• A Signature map must not be a sub-map of any another signature map in the 
SignatureMapTable when it is inserted into this table. 
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• Lastly, the product of Keyword, Profile, and Signature Match Ratios (KPS) of 
a CandidateComponent must exceed a user specified threshold. This allows a 
user to control the amount of retrieved components. 

ResetPreviousVisit resets the VisitingFlags of a query index operation point to a 
component index to a free state so that other query operations can be assigned to. SortAs- 
signment determines whether a query sort can be assigned to a component sort. If a sort 
assignment can be made the SortAssignmentTable will be updated to reflect this. Upda- 
teOal updates the OperationAssignmentTable if the profile and sort of a query operation 
are compatible with a component operation. Finally, the Push/Pop operations are used as 
stack operations for storing and retrieving of state variables such as OperationAssign¬ 
mentTable, SortTableAssignment, VisitingFlags, and component and query indexes during 
the course of execution of the SignatureMatch. 

E. GROUND EQUATION CHECKING 

Figure 10 shows the high level structure of Ground Equation Checking. It is imple¬ 
mented by TranslateGroundEquation, ExecuteTestCase, SemanticRank. 



Figure 10 Structure of the Ground Equation Checking 
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TranslateGroundEquation translates query ground equations into component 
ground equations using all the possible signature maps found by the SignatureMatch mod¬ 
ule (discussed previously). This module sets the translation flag to indicate whether a 
ground equation was successfully translated. ExecuteTestCase issues an instantiation 
statement (OBJ3 Make Statement) if the component is a generic one. It then appends the 
translated ground equations at the end of the component along with the comments that 
explain which of the possible signature maps is used along with the original query ground 
equation. Finally, it invokes OBJ3 to perform term rewriting on these translated ground 
equations. This invocation is performed through a Unix Script file called Runohj. The 
result of this execution is then redirected to an output file called Testrun.dat. Semanti- 
cRank reads the result from Testrun.dat and computes the SemanticRank for a component 
using the equations stated in the Ordering Semantic Matches section. Chapter Vni will 
provide detailed examples describing these steps. 

F. RANKING FORMULATION 

Figure 11 shows the high level structure of Ranking Formulation process. This is a 
simple process. Namely, the ComponentRank is calculated for all the possible maps of the 
component by evaluate the SemanticMatchRatio and KeywordMatchRatio tuple. The cur¬ 
rent implementation will keep the highest value along with its map id. The module Calcu- 
lateTotalRank performs this function. 
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Ranking 

Formulation 


CalculateTotal- 
_ Rank _ 

Figure 11. Structure of the Ranking Formulation 

G. USER INSPECTION AND SELECTION 

Figure 12 shows the high level structure of the User Inspection and Selection pro¬ 
cess. It is implemented by DisplayInvalidOperations and SortDisplayResult. Displayln- 
validOperation displays the invalid operations which do not have the corresponding 
profile in the current software library. It displays the actual invalid operation names so that 
a user can be easily isolate the corresponding ground equation in order that a new query 
formulation can be made. The SortDisplayResult sorts the CandidateComponents in an 
order high to low and displays them. It displays the map id. Keyword Match Ratio and 
Semantic Match Ratio for a user evaluation. A log file under module name (with a file 
extension “tc”) is also available for a user to review. It has all the possible maps along with 
the translated equations. 



50 






VII. EXAMPLES 


A. SOFTWARE COMPONENT RETRIEVAL EXAMPLES 

This chapter provides three examples of the Software Component Search method. 
The reason for including these examples is to illustrate how that the system works and to 
reinforce the concepts described earlier. Each of the examples presents a query specifica¬ 
tion, signature maps, results of the runs submitted against the OBJ3 environment, and the 
final results of the retrieval process. For the purpose of illustration, let us assume that the 
software base consists of components for generic stack, generic queue, generic bag and 
list of natural numbers (a non-generic component). The specifications for these compo¬ 
nents are shown in Appendix B. We also suppose that keywords have been assigned to 
each component as follows: 

Keyword(G-Stack2) = {Booch, Data-Structure, Stack}, 

Keyword(G-Queue) = {Booch, Data-Structure, Queue}, 

Keyword(G-Bag) = {Booch, Data-Structure, Bag}, 

Keyword(N-List) = {Booch, Data-Structure, List} 

Example 5. Query for a stack component: 

Suppose that a user submits a query containing the following information: 

• The keywords are: Booch, Data-Structure, Stack. 

• The partial specification is: 

Package Stack-Of-Nat is Type Stack; 

— Query operations 
function Empty(Out: Stack). 
function Top(In: Stack; Out: Nat) . 
function Push(In: Nat, Stack; Out: Stack). 
function Pop(In: Stack, Out: Stack). 

— Query ground equations 

Top Push(l,Empty) = TopPop(Push(6,Push(l,Empty))) . 

Pop Push(7,Push(l,Empty)) = Push(l,Emty). 

End of Package Stack-Of-Nat; 
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• The selection criterion is to choose a component that has a KPS from 0.50 to 
1.0. The MBN is selected to be 0 (first block). 

The program scans the query to compute the following profile table: 


Operation 

Profile 

Empty 

no 

Top 

220 

Push 

3211 

Pop 

2201 


Table 3: Profile of Operations in Stack-Of-Nat 

We now compute Gp. Gp is the set that contains set 5',, where i is a ground equa¬ 
tion in Q. Let 5, contains profiles of all the operations in a ground equation / in Q. We have 

Gp = {5' j , ^V 2 }, where Sj and S 2 are as follows: 

= {220,3211,110, 2201},^2 " {2201,3211,110} 

Next, the program finds the Keywordids for the query keywords. The program 
now executes the FindCandidateComponent and DepthFirstSearch algorithms to search 
for any nodes whose profile set covers either Sj or S 2 . For such nodes, the program uses 
the ComponentLookupTable to find the corresponding components’s Keywordids and 
Componentid. Using this information, the program calculates the ProfileMatchRatio and 
KeywordMatchRatio, and forwards the components in the node to the signature matching 
procedure. When the query signature is matched against the signature of G-Stack2, G- 
Queue, G-Bag, N-list, the following signature maps are obtained: 
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Query vs. Stack2: 


Vi : Q.S G-Stackl.S' = { {Stack Stack ), {Nat Elt) } 

Vi; Q.I,G-Stackl.I,' = {{Top top), {Push ^ push), 

{Pop -> pop), {Empty create )} 

V 2 : Q.S -> G-Stackl.S’ = {{Stack Stack), {Nat Elt) } 

V 2 : 1 G-Stackl . E' = { ( Top -4 stacksize), {Push -> push), 

{Pop pop ), {Empty create) } 

V 3 : Q.S G-Stackl.S' = { {Stack Stack), {Nat Elt) } 

V 3 ; Q.'L^G-Stackl.'L' = {{Top ^ top), {Pushpush), 

{Pop -> clear), {Empty create) } 

V 4 ; Q.S -> G-Stackl.S' = { {Stack Stack), {Nat -> Elt) } 

V 4 ; 0.1 -> G-Stackl .E' = {{Top^ stacksize), {Push push), 
{Pop clear), {Empty create) } 

V 5 : Q.S G-Stackl.S' = {{Stack Stack), {Nat Elt) } 

V 5 : Q.I, —> G-Stackl.I,' = {{Top—>top), {Push—>push), 

{Pop pop), {Empty -> emptyerror) } 

V 6 ; Q.S G-Stackl.S' = { {Stack Stack), {Nat Elt) } 

¥5 : 0.E —> G-Stackl.Y.' = { (Top stacksize), {Push -> push), 
{Pop pop), {Empty emptyerror )} 

V 7 : Q.S G-Stackl.S' = { {Stack -> Stack), {Nat Elt) } 

V 7 : Q.Y -> G-Stackl.Y' = { {Top -> top), {Push -> push), 

{Pop clear), {Empty -> emptyerror) } 

Vg ; Q.S —> G-Stackl.S' = { {Stack —> Stack), {Nat Elt) } 

Vg ; Q.Y —> G-Stackl.Y' = { {Top —> stacksize), {Push -> push), 
{Pop -> clear), {Empty emptyerror) } 

Query vs. Queue; 

Vj : Q.S —> G-Queue.S' = {{Stack -> Queue), {Nat Elt )} 

Vj : Q.Y-^G-Queue.Y' - {{Top front of), {Pushadd.q), 
{Pop —> pop.q), {Empty -> empty) } 

V 2 : Q.S-¥ G-Queue.S' = { {Stack -> Queue), {Nat -> Elt) } 

Ni '. Q.T.^G-Queue.Y' = { {Top->lengthof), {Pushadd.q), 
{Pop pop.q), {Empty empty) } 

V 3 : Q.S G-Queue.S' = { {Stack Queue), {Nat Elt) } 

V 3 : Q YG-Queue Y' = { {Top front of), {Push ^ add.q), 
{Pop -> clear.q), {Empty empty) } 

V 4 : Q.S G-Queue.S' = { {Stack -> Queue), {Nat Elt )} 
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V 4 : Q.'L-^G-Queue.V = {{Top ^ lengthof), {Pushadd.q), 
{Pop clear.q), {Empty -> empty) } 

Q G-Queue.S’ = { {Stack -> Queue ), {Nat -> Eli )} 

V 5 : QiL-^G-Queue!.’ = {{Top-^fr ontof), {Pushadd.q), 
{Pop -> pop.q), {Empty underflow) } 

Vg : 0 .S' -> G-Queue.S’ = { {Stack -> Queue), {Nat -> £//) } 

Vg : Q!-^ G-Queue.L’ = {(Top -> lengthof), {Push -> add.q ), 
(Po/7 -> pop.q ), {Empty underflow) } 

V 7 ; 0.5' -> G-Queue.S’ = { {Stack -> Queue), {Nat -> £■//) } 

V 7 ; Q .1 ^ G-Queue .1’ = {{Top -^frontof), {Push-¥ add.q), 
{Pop -> clear.q), {Empty underflow )} 

Vg ; 0.5 -> G-Queue.S’ = { {Stack -> Queue), {Nat -> £/0 } 

Vg : 0.1 -> G-Queue.V = { (ro/> -> lengthof), {Push -> add.q), 
{Pop clear.q), {Empty underflow) } 

Query vs. N-list; 

V, ; 0.5 N-List.S’ = {{Stack List), {Nat Nat) } 

V] : Q.L-^N-List.L' = {{Top-^headof), {Pushcons), 

{Pop -> tailof), {Empty nit) } 

V 2 : 0.5 -> N-List.S’ = { {Stack List), {Nat Nat) } 

V 2 ; 0.S -> N-List.l’ = { {Top -> lengthof), {Push cons), 
{Pop tailof), {Empty nit) } 

V 3 ; 0.5 -> N-List.S’ = {{Stack List), {Nat Nat) } 

V 3 : 0.1 -> N-List.V = { {Top -> headof), {Push -> cons), 

{Pop -> clear), {Empty -> nil) } 

V 4 ; 0.5 ^ N-List.S’ = { {Stack -> List), {Nat Nat) } 

V 4 : 0.E N-List.l’ = { {Top -> length ), {Push -> cons), 

{Pop clear), {Empty nil) } 

V 5 ; 0.5 -> N-List.S’ = { (5/ac^ ZwQ, (TVa/ ^ Nat) } 

V 5 : 0.Z -> N-List.I.’ = { (To/? -> headof), {Push cons), 

{Pop -> clearhead), {Empty —> /i/7) } 

Vg : Q.S -> N-List.S’ = { {Stack -> L/ 5 /), (Vaf -> Va/) } 

Vg : 0.E ^ N-List.I,’ = { (7b/> -> lengthof), {Push co/ 15 ), 
{Pop —> clearhead), {Empty —> /i/7) } 

V 7 : 0.5 N-List.S’ = {{Stack -> Z,/ 50 , (Vaf -> AToO } 

V 7 ; 0.1 -> N-List.I' = { {Top headof ), (/^m 5 // sethead), 
{Pop /o/7oy), {Empty -> /i/7) } 

Vg : 0.5 N-List.S’ = { (5/acA: List), {Nat Nat) } 
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Vg : Q.'L-^N-List.I,' = {{Top lengthof), {Push ^ sethead), 

{Pop tailof ), {Empty nil )} 

Query vs. Bag: 

Vi: 0.^ -> G-Bag.S' = { {Stack Bag), {Nat -> Elt) } 

Vj : 0.1 -> G-Bag. I' = { (Top -> lengthof ), {Push add ), 

{Pop clear ), {Empty empty) } 

V 2 : 0.5 -» G-Bag.S’ = { {Stack Bag ), {Nat Elt) } 

V 2 : 0.2 -> G-Bag. 2' = { (Top -> uniqueExtentOf), {Push -> add ), 

{Pop clear ), {Empty empty) } 

V 3 : 0.5 G-Bag.S' = { {Stack -> Bag ), (A^ar ^ Elt) } 

V 3 : 0.2 G-Bag. 2' = {(Top lengthof ), -> remove ), 

(Po /7 -> clear ), {Empty empty) } 

V 4 : Q.S^ G-Bag.S’ = { {Stack -> fiag), -» £//) } 

V 4 : 0.2^ G-Bag.!.’ = { (Top -> uniqueExtentOf), {Push -> remove), 
{Pop -> clear ), {Empty empty) } 

Once the computation of signature maps is complete, the following steps are performed: 

• Translate the query ground equations by applying V. 

Query vs. Stack2: 

Vj; {Q.Eq\-^G-Stack2.Eq\): 

( ( Top {Push { 1, Empty) ) = Top {Pop {Push ( 6 , Push { 1 , Empty) ) ) ) ) ) -> 

({top {push ( 1 , create)) = top {pop{push ( 6 ,push { 1 , create)))))) 

V,: {Q.Eq2^G-Stack2.Eq2) : 

{Pop {Push (7, Push {\, Empty) ) ) = Push ( 1 , Empty) ) —> 

{pop {push (7, push (1, create) ) ) = push (1, create) ) 

Query vs. Queue: 

Vi : {Q.Eql G-Queue.Eq\) : 

((Top {Push { 1, Empty) ) = Top {Pop {Push ( 6 , Push (I, Empty )))))) 

( {frontof{ad3.Q { 1, empty) ) = 
frontof {pop. 0 {add. 0 ( 6 , add. 0 ( 1 , empty) ) ) ) ) ) 
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Vj : (Q.Eql —> G-Queue.Eq2): 

(Pop (Push (7, Push (1, Empty) ) ) = Push ( 1 , Empty) ) -> 

(pop.Q(add.Q (7, add.Q(I, empty))) = add.Q(\, empty)) 

Query vs. List: 

V, : (Q.Eq\ -^N-List.Eql) : 

((Top (Push ( 1 , Empty) ) = Top (Pop (Push ( 6 , Push ( 1 , Empty) ) ) ) ) ) 

((headof (cons ( 1 , nil )) = headof (tailof (cons (6, cons ( 1 , nit ))) ))) 

Vi: (Q.Eql^N-List.Eql): 

(Pop(Push (1,Push(\,Empty))) = Push (\, Empty)) -> 

(tailof (cons(1, cons(\, nil))) = cons(\, cons)) 

Query vs. Bag: 

Vj : (Q.EqX G-Bag.Eq\) : 

((Top (Push ( 1 , Empty) ) = Top (Pop (Push ( 6 , Push ( 1 , Empty )))))) 

( (Lengthof (add ( 1, empty) ) = 

lengthof (clear (add(6, add ( 1 , empty) ) ) ) ) ) 

Vi : (Q.Eql G-Bag.Eq2): 

(Pop (Push ( 7, Push ( 1 , Empty) ) ) = Push ( 1 , Empty) ) 

(clear (add (7, add(\, empty ))) = add (1, empty) ) 

The translated ground equations are only shown only here for first mapping. In the 
course of execution, all the translated ground equations for all signature matches 
will be considered for GroundEquationChecking, which also does the following: 

• Instantiate the formal parameter(s) with actual parameter(s) using the OB J3 
make command. This yields an non-generic component. This step is used on 
G-Queue, G-Stack, G-Bag, but not N-list since it is not a generic component 
The sort correspondence in the signature match is used to determine the actual 
parameter for the instatiation. 

• Append the translated ground equations to the end of G-Queue, G-Stack, G- 
Bag, and N-List OBJ3 code, with the OBJ3 reduce command. 

As an example, these transformations are shown below for Nat-Stack2 (G-Stack2 
with Nat instantiation). Note that for the purpose of illustration, the author only 
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shows the first one signature map out of the total of eight: The lines starting with 
the symbol (“*”) are comment lines. 


obj Stack2[X :: TRIV] is sort Stack . 
protecting NAT . 
op create : -> Stack . 
op copy : Stack Stack -> Stack . 
op clear : Stack -> Stack . 
op push : Elt Stack -> Stack . 
op pop : Stack -> Stack . 
op empty : -> Stack . 
op top : Stack -> Elt. 
op depthof: Stack -> Nat. 
op isempty : Stack -> Bool. 
op isequal: Stack Stack -> Bool. 
op StackError : -> Stack . 
op StackError : -> Elt. 
var S SI S2 : Stack . 
var X : Elt. 
eq clear(S) = empty . 
eq copy(empty,S) = clear(S), 
eq copy(push(X,Sl),S2) = push(X,copy(Sl,S2)). 
eq top(empty) = StackError . 
eq top(clear(S)) = StackError. 
eq top(push(X,S)) = X . 
eq pop(empty) = StackError . 
eq pop(clear(S)) = StackError. 
eq pop(push(X,S)) = S . 
eq pop(create) = StackError. 
eq depthof(empty) = 0 . 
eq depthof(create) = 0 . 
eq depthof(push(X,S)) = 1 + depthof(S). 

eq isempty(S) = if (S == create) or (S — empty) then true else false fi. 
eq isequal(Sl,S2) = if SI == S2 then true else false fi. 
endo 

make testobj is Stack2[NAT] endm 


1 1 M M 1 

*** Map # 

4c** 1 » « » 1 < 1 

1 1 t 

1 

*** Sort Assignment: 

*** Stack 

->Stack 

*** NAT 

->Elt 

Operator Assignment: 

*** Empty 

->create 

Push 

->push 

*** Pop 

->pop 

Top 

->top 
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***GrdEq:Top(Push(l ,Empty))==Top(Pop(Push(6,Push(l .Empty)))), 
reduce top(push(l,create))=top(pop(push(6,push(l,create)))). 

GrdEq:Pop(Push(7,Push( 1 .Empty )))==Push(l .Empty), 
reduce pop(push(7.push) 1,create))) ==push(l.create). 


• This specification now is ready to be given to OBJ3 by a Unix script file called 
Runobj (see Appendix D). The result of this execution directed to a file called 
Testrumdat. Note that the real OBJ3’s output file also contains other things, 
such as the OBJ header. This information is removed. The final result is stored 
in Testrun.dat. This file contains the following data: 

Bool: true 
Bool: true 
Bool: true 
Bool: true 
Bool: false 
Bool: false 
Bool: false 
Bool: false 
Bool: true 
Bool: true 

The first two Bool statements correspond to the first signature map for the two trans¬ 
lated ground equations (shown previously). They are term-rewritten to be true. The rest of 
the Bool statements correspond to the rest of the term-rewritten translated ground equa¬ 
tions for the rest of the signature maps. Next the program reads this data to compute the 
SemanticRank. Finally, the ComponentRank for each component is computed. The result 
of a retrieval session for the Stack-Of-Nat query is shown below; 

The result of your retrieval session is: 

Find component: Stack2.obj 
Using Map Number: 1 

The ComponentRank: ( 2.0E-K)0,1 .OE+OO) 

Find component: list.obj 

Using Map Number: 1 

The ComponentRank: (2.0E’K)0,6.7E-01) 
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Find component: queue.obj 

Using Map Number: 2 

The ComponentRank: (1.0E*H)0,6.7E-01) 

Find component: bag.obj 

Using Map Number: 3 

The ComponentRank: (0.0E-K)0,6.7E-01) 

We note here that the ComponentRank is a 2-tuple value. The first field of the 2- 
tuple represents the SemanticMatchRatio and the second field is the KeywordMatchRatio. 
There is only one component that fully meets the query, namely, G-Stack2. N-List is 
ranked second, since it has a lower KeywordMatchRatio. However, it fully meets the 
SemanticMatchRatio. G-Queue is ranked third since it has the lowest SemanticMatchRa¬ 
tio. Finally, G-bag is ranked fourth since it completely fails the semantic evaluation. The 
end result of the retrieval session suggests that we can use G-Stack2 or N-list for the 
Stack-Of-Nat queiy. 

Example 6. Query for a set component: 

In this example, we are adding a new generic set component into our library. The 
specification for this set component is shown in Appendix B. Let us suppose that a user 
submits a query which consists of the following operations; 

• Union: Given two sets, form a set containing the items that are members of the 
first set or the second set. 

• Subset: Return true if the first set is a subset of the second set. 

• Intersection; Given two sets, form a set containing the items that are members 
of the first set and the second set. 

• Insertion; Insert an item as a member of the set. 

• Cardinality: Return the current number of items in the set. 
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• Equal: Return true if the two given sets have the same state and false other¬ 
wise. 

• Clear; Remove all the items from the set and make the set empty. 

• Create; A set constant. 

• Copy; Copy the items from one set to another set. 

A user further wants to look for a component that has the following semantic samples; 

• Eq 1; Clearing an non-empty set is the same as copying an empty set to a set. 

• Eq 2; A set that contains elements of another set is a subset of that set. 

• Eq 3; An empty set should be a result of applying an intersection operation on 
two disjoint sets. 

• Eq 4; The result of the union of two sets is equal to a set that contains their ele¬ 
ments. 

• Eq 5; The cardinality of a set is the occurrences of the elements in that set. 

Formally, these semantic samples are expressed as ground equations together with their 

operations in a partial specification below; 

Package Set-Of-Nat is Type Set; 

— Operations: 

Function: Union(In: Set, Set; Out: Set). 

Function: Subset(In: Set,Set; Out: Boolean). 

Function: Intersection(In: Set,Set; Out: Set). 

Function: Cardinality(In: Set; Out: Boolean) 

Function: Insert(In: Nat,Set; Out: Set). 

Function: Equal(In: Set,Set; Out: Boolean) 

Function: Create(Out: Set). 

Function: Clear(In: Set;Out: Set). 

Function: Copy(In: Set, Set; Out: Set). 

— Ground equations: 

Eql: Clear(Insert(l,create)) = Copy(create,Clear(Insert(l,Create))). 

Eq2: Subset(Insert(l,Insert(2,Create)),Insert(l,Insert(3,Insert(2,Create)))) = True . 

Eq3: Equal(Create,Intersection(Insert(l,Create),Insert(3,Insert(2,Create))) = True . 

Eq4: Equal(Insert(l,Insert(2,create)),Union(Insert(l,Create),Insert(2,Create))) = True . 

Eq5: Cardinality(Insert(l,Insert(2,Insert(3,Insert(4,Insert(5,Create)))))) = 5 
End of Package Set-Of-Nat; 
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A user further chooses the following Keywords: Booch, Data-Stmcture, and Set. 
Having a high confidence in finding this component, a user chooses a KPS from 0.9 to 1.0. 
Finally, a MBN of 0 is also selected for retrieval. The following is the actual output of the 
SCS program given the query data above. 

The result of your retrieval session is: 

Find component: set.obj 

Using Map Number: 15 

The ComponentRank: (4.0E-KX), 1.0E-K)0) 

This result says that we have found a full match. The KeywordMatchRatio is equal 
to 1.0 since every thing is matched. Due to the equations 3 and 4 having the same top 
function “Equal”, the SemanticMatchRatio is 4.0 instead of 5.0 (for 5 ground equations). 
This is exactly equal to the semantic ranking scheme that we have proposed early in sec¬ 
tion 5.1. This result is obtained using a signature map number 15 from log file called 
Set.obj tc. It is as follows: 


***Map# 15 

A** 1 1 1 1 1 1 1 1_1 -1 -1 

-H- 

*** Sort Assignment: 

Set 

->Set 

NAT 

->Elt 

*** BOOL 

->BOOL 

Operator Assignment: 

*** Create 

->create 

*** Insert 

->add 

Cardinality 

->cardinaiity 

*** Clear 

->clear 

Union 

->union 

*** Equal 

->isequal 

*** Intersection 

->intersection 

*** Subset 

->subsetof 

*** Copy 

->copy 
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If we look closer at the sort and operation assignment, they look almost the same. 
The result of this retrieval session says that we have successfully located a reusable com¬ 
ponent call Set. 

Example 7. Query for a Ring component: 

In our final example, a Ring component is added into the library. The specification 
of this Ring component is shown in Appendix B. Ring data structure is a sequence of zero 
or more items arrange in a circular fashion. Because this structure wraps around itself, it is 
highly symmetrical and has many usefiil applications ranging from manipulation of poly¬ 
nomials to user interface. Suppose now that a user is interested in a Ring Component. The 
operations requested are: 

• Forward: Forward Direction (clockwise). 

• Empty: Ring constant represent an empty string. 

• Adding: Add an item at the top of the ring. 

• Pop: Remove an item at the top of the ring. 

• Rotation: Rotate the ring in a given direction. 

• Cardinality: Return the current number of items in the ring. 

• TopofRing: Return the item at the top of the ring. 

• Testing: This operation is used only for the testing of an operation that is not 
valid under a software library. 

A user further wants to look for a component which has the following semantic samples: 

• Eql: Adding an element to a top of an empty ring and removing it results in an 
empty ring. 

• Eq2: The top element of a ring should be the most recently added one. 

• Eq3: The element in a ring is the number of elements added in an empty ring. 
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• Eq4: The forward rotation of a 3 element ring should move each element two 
positions clockwise. 

• Eq5; This equation is used for testing of an unknown operation (invalid pro¬ 
file) in a software library. 

The information above can be formalized as a partial specification as follows: 

Package Ring-Of-Nat is Type Ring; 

Import Type Direction; 

- Operations: 

Function: Forward(Out: Direction). 

Function: Empty(Out: Ring). 

Function: Cardinality(In: Set; Out: Boolean). 

Function: Adding(In: Nat,Ring; Out: Ring). 

Function: Pop(In: Nat,Ring; Out: Ring). 

Function: Rotation(In: Direction,Ring; Out: Ring). 

Function: TopofRing(In: Ring; Out: Nat). 

Function: Testing(In: Ring,Ring,Ring,Ring; Out: Ring). 

— Ground equations: 

Eql: Pop(Adding(l,Empty)) “Empty . 

Eq2: TopofRing(Adding(l,Adding(2,Adding(3,Empty)))) = 1 . 

Eq3: Extentof(Adding(2,Adding(3,Adding(l,Empty)))) == 3 . 

Eq4: Rotation(Forward,Adding(l,Adding(3,Adding(2,Empty)))) — 

Adding(3,Adding(2,Adding( 1 ,Empty))). 

Eq5: Testing(Empty,Empty,Empty,Empty) = Empty . 

End Of Ring-Of-Nat; 

This time a user chooses the following ke 5 rwords: Booch, Data-Structure, and Ring. 
Since a user is also interested in partial matching, a KPS of 0.6 to 1.0 is selected. Two 
retrieval sessions will be shown for this query due to the number of partial mappings being 
very large. The result of the first retrieval session is as follows: (we are using a MBN of 0 
for the first 85 maps) 

The result of your retrieval session is: 

Find component: stackl.obj 

Using Map Number: 14 

The ComponentRank: (3.0E-K)0,6.7E-01) 

Find component: Stack2.obj 
Using Map Number: 2 

The ComponentRank: (3.0E‘K)0,6.7E-01) 
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Find component; ring.obj 

Using Map Number: 2 

The ComponentRank: (2.0E-K)0,1.0E+00) 

The following operation(s) is unknown: Testing 

We further review how the results are formulated by looking at maps number 2 and 
14 in the log files for Stackl.obj.tc and Stack2.obj.tc. This data shows that ground equa¬ 
tions 1,2, and 3 were term-rewritten to be true. However, equation 4 can not be translated 
due to some of the operations in this equation being undefined. Even though the Keyword- 
MatchRatio is high, component Ring ranks second (both Stackl and Stack2 rank first) due 
to a low SemanticRank. Next, we go further by looking at the block 1 of the signature 
maps (the next 85 maps). The retrieval result of the second retrieval session using exactly 
the same query formulation is as follows: 

The result of your retrieval session is: 

Find Component: ring.obj 

Using Map Number: 65 

The ComponentRank: (4.0E+00,i .0E-K)0) 

The following operation(s) is unknown: Testing 

This result indicates that Ring component is a better matched component than 
stackl or Stack2 since the Ring’s ComponentRank is much higher than both. This is so 
because the SemanticMatchRatio value is higher than the previous session. Further 
reviewing of the result in the log file of the Ring component indicates that the first four 
ground equations are rewritten to be true. The final result also warns a user that operation 
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“Testing” from the query formulation is not visible in the current software library. This is 
reported in both retrieval sessions. 

In conclusion, the end result of these three examples shows the system can: 

• Retrieve reusable software components. 

• Discriminate between components in order to provide to a user an indication of 
which component is a better match. The system can tell the user how close or 
further apart the retrieved component is relative to a query. 

• Provide useful information to explain how the result is formulated at the end of 
the retrieval session. 

• The formulation of the query is clear, friendly enough and not so difficult that a 
user would not be able to use and comprehend. 

• Isolate invalid operations that will help a user to reformulate a new query if 
needed. 

• Retrieve both generic and non-generic components. 
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VIII. EXPERIMENTATION 

A. INTRODUCTION 

This chapter provides the important experimentation results to assess the practical use¬ 
fulness of the proposed method for retrieving reusable software components. Five differ¬ 
ent experiments were performed. The first experiment evaluates the user‘s competence in 
formulating the ground equations for retrieval of software components. The second and 
third experiments deal with the performance of the system in relation to the Signature 
Matching Algorithms. The fourth experiment describes the analysis and performance of 
the software library using the Hasse Diagram as a model. The fifth experiment provides 
some results regarding the retrieval performance of the system. 

B. EVALUATION USING PARTIAL SPECIFICATIONS AS QUERIES 

As proposed in this dissertation, using partial specifications (test cases) as a query 
for software components is a relatively easy task that can be performed by a typical soft¬ 
ware engineer. For a software component retrieval task, formal specification is considered 
by the author as overkill, unfriendly, time consuming, and inflexible for reformation of 
queries. Because it is easy to comprehend and simple to construct, partial specification as 
query could help to overcome some these difficulties. The experiment describes below is a 
measurement to check the aforementioned conjectures. 

An assignment was given to CS-4520 (Advance Software Engineering class at 
NPS) students to: (1) write two formal specifications for the two software components in 
the Booch software library, (2) verify the correctness of these specifications by formulat- 
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ing test cases (ground equations) using only ground terms, (3) evaluate the following 
assessments: 

• Comparing the difficulty in writing formal specification to ground equations. 

• Assess whether a software engineer without the knowledge of formal specifi¬ 
cation could write ground equations for the retrieval of software component 
task. 

• Provide some guide lines to help the user in formulating queries. 

• Assess whether OBJ3 can be used for specifying reusable software compo¬ 
nents. 

The result from these assessments are as follows: 

• 83% of the students believe that the formulation of ground equations is signifi¬ 
cantly easier than writing the complete specification for modules. Most stu¬ 
dents claimed having difficulties in formulating axioms in the beginning of the 
writing formal specifications due to a change of mind set from procedural lan¬ 
guages to rewrite rules. Some others students have some difficulty in formulat¬ 
ing axioms due to the involvement with recursiveness in some problems. 

• 66% of students believe that a software engineer can formulate such ground 
equations without the knowledge of algebraic specification. This assumes that 
he/she knows what are the operations required, and understand the desired 
behavior of the sought component(s) with respect to these operations. 

• The important guidelines to supporting the users in formulating the query 
through ground equations are as follows: 

• A user should start with the most basic primitive operations and then 
incrementally test other complex operations. This is like description in 
a piece-meal fashion. A user learns more about the search components 
as the search process continues. 

• Per query, a user ought to keep a manageable size of operations and 
ground equations such that he/she can keep track of the semantics of 
the search component(s). 

• To further discriminate between components, a user should form 
ground equations that check on boundary conditions as well as repre¬ 
sentative samples. 
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• A user should avoid using too many repeated terms in order to reduce 
the amount of term rewriting. This will speed up the term rewnting pro¬ 
cess. 

• A user should differentiate between constructors and accessors in order 
that ground equations can be formulated correctly. 

• 83% of students believe that OBJ3 has a real potential usage in specify reus¬ 

able software components. One big problem is that writing the OBJ3 specifica¬ 
tion is as error prone as programming. If this scheme is chosen, an OBJ3 
specification must be well documented, tested and approved by a committee 
before insertion into a software library. The second problem with OBJ3 is that 
its error messages come back to the user are difficult to comprehend and mis¬ 
leading sometimes. 


C. SIGNATURE MATCfflNG ALGORITHMS PERFORMANCE 

As described earlier, SignatureMatch algorithm uses the profile definition as a way 
to eliminate a useless component operation when a query operation is being matched 
against it. This is indeed an approximate signature matching process. This experiment 
serves three purposes: 

• To verify the correctness of this approximation to assure that no component 
operation is eliminated wrongly when it is matched against a query operation. 

• To measure the efficiency in the reduction of the number of computational 
operations required when profile definition is used. 

• To validate Theorem 1 stated in Chapter IV and proved in Appendix E. 

One approach for verifying this experiment is to eliminate the profile equality 
check in Chapter V (also see item six of the Signature Matching Requirements) of the Sig¬ 
natureMatch algorithm. By doing this, we allow any query operation to pair with any com¬ 
ponent operations with only the remaining 6 restrictions mentioned in section IV.4. To 
verify the correctness, two separate executions were made, one with and one without pro- 
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file approximation. The end results of the two retrieval sessions were compared to see if 
the retrieved components chosen from the two executions are the same. In addition to this, 
their corresponding rankings and signature maps were also compared for equality. This 
experiment is performed using the same query as in Example 7 of Chapter VI. This query 
was executed together with two separate Signature Matching Algorithms, The first one, 
SMatchl, uses approximation while the second one, SMatch2, does not. Finally, a counter 
was inserted into these algorithms to count the number of the pairs of query and compo¬ 
nent operation that must be evaluated with and without including profile as equality check. 
The result of this experiment is summarized as follow: 


Algorithm 

Stack2 

Bag 

Queue 

Stack 1 

N-List 

Ring 

SMatchl 

302 

494 

500 

674 



SMatch2 

2937 

57677 

11042 

16910 

27152 

1251649 


Table 4: Number of the Pais of Query and Component Operation Performed for 
SMatchl and SMatch2 Using the Query from Example 7 


Once this result is obtained, the retrieved component of both SMatchl and 
SMatch2 are compared and evaluated. It turns out that both SMatchl and SMatch2 pro¬ 
duce the same result. Only Ring component was retrieved. The Ring’s SemanticRanks for 
both SMatchl and SMatch2 have the same value. In addition, the signature maps that were 
used to calculate the ComponentRank for the Ring component were exactly the same. The 
second part of this experiment was to come up with some timing information in order that 
we can appreciate the effort in using approximation for signature matching process. This 
experiment concludes that by using profile definition to approximate the signature match- 
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ing process, we are able to produce the same result in a very much shorter time (about 56 
times faster than using no approximation). This result also confirms Theorem 1 stated in 
Chapter IV. 

D. REDUCTIONS OF USELESS MAPS 

A goals of this dissertation is not only to demonstrate a proof of concept but to also 
try to make it into as practical a tool as possible. A challenge for the SignatureMatch algo¬ 
rithm is trying to retain only the useful maps and to discard the useless ones. This helps to 
reduce the storage capacity and to improve the speed of the retrieval process. This experi¬ 
ment provides statistical data to demonstrate that this reduction indeed helps with this pro¬ 
cess. The current prototype uses two different filtering stages to eliminate useless maps. 
The first stage rejects maps that are either duplicates or sub-maps of the maps that are cur¬ 
rently residing in the SignatureMapTable. The second stage eliminates maps that do not 
have at least one translatable “top” function. For the purpose of efficiency, these map fil¬ 
tering stages are implemented as short-circuit operators (in Ada) to speed up the execu¬ 
tion. To assure that no map is eliminated wrongly, this experiment was performed on 
separate executions using the query in Example 5. The first one, Execl, included both 
elimination of redundant/sub-maps and nontranslateable “top” function map. The second 
one, Exec2, involved only the elimination of redundant/sub-map maps. Finally, the third. 
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Exec3, involves no elimination of maps. The following table summarizes the results of 
these executions: 



Stack 1 

Stack2 

Queue 

Bag 

N-List 

Ring 

Execl 

12 

S 

8 

17 

48 

72 

Exec2 

12 

8 

8 

17 

49 

74 

Exec3 

168 

125 

126 

81 

351 

298 


Table 5: Number of the Maps Include as Part of the Three Executions Using the 


Query from Example 5. 

In the same fashion as in Experiment 2, the end results of these executions were com¬ 
pared. As expected, the prototype was able to retrieve the same components for the three 
executions. However, Exec3, took longer to complete than Exec2 and Execl, because all 
of the useless maps need to be evaluated before the final result can be produced. This is 
confirmed with given number of maps shown in row 3 in Table 5 above. Table 5 also indi¬ 
cates that there is some reduction from Exec2 to Execl, but it is not very much. 

This experiment also gives a rough idea of a number of maps that a Signature- 
Match algorithm produced. It provides a significant improvement for the system in terms 
of maps storage and execution. However, even with these reduction techniques, some test 
data indicates that the number of maps can possibly go up to 400 maps when all possible 
maps were considered. This is the worst case when all the partial maps were chosen. 
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E. MODEL OF A SOFTWARE LIBRARY 

Another issue address by this dissertation is how a software library can be con¬ 
structed so that it helps with the retrieval process. Without a software library model, the 
approach proposed in this dissertation would be too costly if every single component from 
a library must be evaluated through signature and semantic matching before a system can 
produce the result. There must be a way such that these matching procedures can be 
directed to only work on the candidate components that are highly desired by a user (and 
not the useless ones). To satisfy this requirement, an approach has been proposed in Sec¬ 
tion IV.3. In this chapter, a smaller scale model of a library is constructed to analyze, test 
and verify the theory of this proposed model. The currently ongoing work of [36] and [37] 
will implement and carry this idea further. 

1. General Discussion of the Software Library Components 
For this experiment, a collection consisting of twelve useful data structures from 
the Booch reusable software library [39] was selected. They are as follows: Array, Bag, 
Binary Tree version 1, Binary Tree version 2, Deque, Queue, List version 1, List version 
2, Set, Stack version 1, Stack version 2, and Ring. These modules were written in OBJ3 
language by the students (including the author) from the CS-4520 class as a course 
project. After that, the author further refined the spedfication to: (1) unify the syntax so 
that the prototype can work with, (2) make minor corrections for improvement, (3) include 
documentation, (4) collect their profile definition, and (5) finally, populate them into the 
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Figure 13. A HasseDiagram Represents a Software Base Partition 

















simulated software library (as a Hasse diagram) to integrate them with the prototype. 
Table 6 summarizes the profile values with respect to the components. Figure 13 models 
a software library for the twelve components using a Hasse diagram. 

2. Analysis of Software Library using Hasse Diagram 

Algorithm DepthFirstSearchForward is responsible for the retrieval process of 
software components. As a depth-first search-based algorithm, its traversal time complex¬ 
ity is 0(P+ R) using an adjacency list. P represents the number of partitions and R rep¬ 
resents the inclusive relations in the Hasse diagram. The time complexity of retrieval of 
candidate component is 0({\P\yMaxProfileSet)+\MatchedComponents\) . The 
product of (|PI X MaxProfileSet) is the cost for finding partitions that contain candidate 
components. The cardinality of \MatchedComponents\ is the cost for outputting the 
matched components. The space complexity is as follows: 

0{\P\ + \Profile\ + MaxProfileSetSize + \Componenis\ + |i?|) 

3. A Simulation Study and Evaluation 

Suppose, a user enter a following query; 

Package Set-Of-Nat is Type Set; 

— Operations: 

Function: Union(In: Set, Set; Out: Set). 

Function: Subset (In: Set, Set; Out: Boolean). 

Function: Intersection(In: Set,Set; Out: Set). 

Function: Cardinality (In: Set; Out: Boolean) 

Function: Insert(In: Nat,Set; Out: Set). 

Function: Equal (In: Set, Set; Out: Boolean) 

Function: Create(Out: Set). 

Function: Clear(In: Set;Out: Set). 

Function: Memberof(In: Nat, Set; Out: Bool) 

“ Ground equations: 

Eq: Memberof(l,Insert(l,Create)) = True . 

End of Package Set-Of-Nat; 

Given this query, the system computes the profile values for the query operations. 
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After that it identifies the profile values for the MemberOf, Insert, and Create. They are 
330 (P5), 3211 (P4), and 110 (PI) (see Figure 13 and Table 3). Next FindCandidateCom- 
ponents calls DepthFirstSearchForward to look for any partition which has a set of pro¬ 
files containing 330, 3211, and 110. There are two partitions that satisfy this condition. 
These partitions are 3 and 5 (see Figure 13). They include in the following components: 
Set, Array, Bag, Listl, and List2. The rest of the modules are not retrieved since they do 
not belong to a partition which contains profile 330. The following is the actual result col¬ 
lected from an execution: 


The result of your retrieval session is: 

Find Component: set.obj 

Using Map Number: 1 

The ComponentRank: (1.0E-K)0,1 .OE+00) 

Find Component: array.obj 

Using Map Number: 2 

The ComponentRank: (1.0E'K)0,6.7E-01) 

Find Component; list2.obj 

Using Map Number: 84 

The ComponentRank: ( 0.0E-KX),6.7E-01) 

Find Component: listl.obj 

Using Map Number: 84 

The ComponentRank: (0.0E+00,6.7E-01) 

Find Component: bag.obj 

Using Map Number: 84 

The ComponentRank: ( 0.0E+00,6.7E-01) 

The result from this execution indicates that Set is the best component. It has a 
full match value for Keyword and Semantic Match Ratios. The component such as Array 
is partially matched. Listl, List2, and Bag are the worst ones because they fail the 
semantic check. That is why their ComponentRank is 0.0. 

To convince ourselves that these components retrieved above are indeed the 
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correct ones, all twelve components are selected and executed against the 
SignatureMatching and Ground Equations. The results are correlated with the previous 
execution to check that we did not discard any potential candidate component. Here is 

the result of this execution: 

The result of your retrieval session is: 

Find Component: set.obj 

Using Map Number: 1 

The ComponentRank: (1.0E“K)0,1.0E-K)0) 

Find Component: array.obj 

Using Map Number: 37 

The ComponentRank: (1 .OE+OO, 6.7E-01) 

Find Component: bintl.obj 

Using Map Number: 1 

The ComponentRank: (0.0E*K)0,6.7E-01) 

Find Component: deque.obj 

Using Map Number: 42 

The ComponentRank: (0.0E-K)0,6.7E-01) 

Find Component: ring.obj 

Using Map Number: 80 

The ComponentRank: (0.0E+O0,6.7E-01) 

Find Component: list2.obj 

Using Map Number: 83 

The ComponentRank: (0.0E“K)0,6.7E-01) 

Find Component: listl.obj 

Using Map Number: 83 

The ComponentRank: (0.0E-K)0,6.7E-01) 

Find Component: bag.obj 

Using Map Number: 63 

The ComponentRank: (0.0E+00,6.7E-01) 

Find Component: queue.obj 

Using Map Number: 42 

The ComponentRank: (0.0E-K)0,6.7E-01) 

Find Component: bmt2.obj 

Using Map Number: 42 

The ComponentRank: (0.0E-K)0,6.7E-01) 
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Find Component: stackl.obj 

Using Map Number: 42 

The ComponentRank: (0.0E“K)0,6.7E-01) 

Find Component: stack2.obj 

Using Map Number: 23 

The ComponentRank: (0.0E“K)0,6.7E-01) 

This result confirms that the components which have not been selected in the pre¬ 
vious execution, such as Bintl, Stackt2, Stackl, Bint2, Queue, Ring, and Deque have a 
SemanticMatchRatio of 0.0 because no translated equation could be was produced for 
them. These components do not have a profile value of 330 or 3211. That is why they are 
excluded from the first execution. We have eliminated the useless components which 
would be wasteful and costly (in term of execution time) if they had been included in the 
retrieval session. This elimination makes the method useful and practical when the num¬ 
ber of software components in the library becomes large. 

Our final study with the software library is to see how a partial match of a compo¬ 
nent can be obtained. So far, for demonstration purposes, we only have one ground equa¬ 
tion. Suppose now, a user adds in another ground equation as follows: 

Eq; Subset(Insert(l,Insert(2,Create)), 

Insert( 1 ,Insert(3,Insert(2,Create)))) = true. 

With this new ground equation, an additional set of profiles is computed. This set 
has the following elements: 3210, 3211, and 110. We begin to search for the Candidate- 
Components in the library; this set of value will be checked against the partitions in the 
library. If any component which belongs to a partition that contains either {3210, 3211, 
110} or (330,3211,110} (the previous ground equation) will be considered as a candidate 
component. In this case, looking at Figure 5, the components Stackl, Queue, Ring, Deque, 
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and Bint2 will be considered as candidate components in addition to the components 
selected in the last session. Here is the execution to verify this: 

The result of your retrieval session is: 

Find Component: set.obj 

Using Map Number: 1 

The ComponentRank: ( 2.0E'K)0,1.0E-K)0) 

Find Component: array.obj 

Using Map Number: 1 

The ComponentRank: (1 .OE+OO, 6.7E-01) 

Find Component: deque.obj 

Using Map Number: 42 

The ComponentRank: (1.0E-K)0, 6.7E-01) 

Find Component: queue.obj 

Using Map Number: 83 

The ComponentRank: (l.OE+OO, 6.7E-01) 

Find Component: bint2,obj 

Using Map Number: 74 

The ComponentRank: (1 .OE+OO, 6.7E-01) 

Find Component: stackl.obj 

Using Map Number: 83 

The ComponentRank: (1 .OE+OO, 6.7E-01) 

Find Component: ring.obj 

Using Map Number: 80 

The ComponentRank: (O.OE+00, 6.7E-01) 

Find Component: list2.obj 

Using Map Number: 83 

The ComponentRank: (O.OE+00, 6.7E-01) 

Find Component: list l.obj 

Using Map Number: 83 

The ComponentRank: (O.OE+00, 6.7E-01) 

Find Component: bag.obj 

Using Map Number: 63 

The ComponentRank: (O.OE+00, 6.7E-01) 

Find Component: stackl.obj 

The ComponentRank: (0.OE+OO, 6.7E-01) 

From this example, we can see that additional components are included due to the 
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second ground equations. It turns out that these components have a very low ranking and 
may not contribute much to a user’s expectation. However, the system should be able to 
provide a user with such partial matches in case a user is not satisfied with the better 
matches. Since a user has control over the search process via the selection criteria, he/she 
can specify how well the components are matched against his/her query. This would limit 
the number of matched components to a manageable size so that a user can make a selec¬ 
tion with ease. The execution above was executed using a KPS value of 0.0 to 1.0 to allow 
all components to be evaluated. If a user has chosen a KPS of 0.8 to 1.0, then only the Set 
component would show up. 

F. RETRIEVAL PERFORMANCE 

In this section we perform the retrieval measurement for this model. Here we do 
not try to do an extensive large scale measurement but rather a study to see how the sys¬ 
tem stands up against two well known critical evaluations [4]. They are Recall and Preci¬ 
sion. Recall is defined as; 

\RelevantComponentsRetrieved\ 

\RelevantComponentsInLibrary\ 

Precision is defined as; 

_ . . \RelevantComponentsRetrieved\ 

= - \Compo„er,lsRetrieve4 - 

1. Experimental Description 

There are 18 different query sessions performed for tfiis experiment using the same 
simulated software library discussed in the previous experiment. These sessions consist of 
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6 different query formulations using 3 different KPS scenarios. The 6 queries are designed 
to retrieve the following components: Bag, List, Queue, Set, Ring, and Stack. Each query 
consists of a set of keywords, operations, and a ground equation that characterizes an indi¬ 
vidual component. The 3 KPS scenarios are chosen with Low (0.0-1.0), Medium (0.6-1.0), 
and High (0.9-1.0). Once a retrieval session is complete, the ComponentRanks are tabu¬ 
lated in Table 7. For each query, the retrieved components are evaluated to determine their 
relevance and cross-checked against the expected ones. Finally, the recall and precision 
values are computed for this query session. They are also tabulated in the same table (col¬ 
umn 2). Note that the left most column of Table 7 identifies the a user query. The “-1”, “- 
2”, and “-3” represents the KPS scenarios: Low (0.0-1.0), Medium (0.6-1.0), and High 
(0.9-1.0). 
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De¬ 
stack Stack Bint2 Queue Set Array Bag Listl List2 Ring 



Table 7: Recall/Precision Measurements for 3 Different KPS scenarios 







































2. Experimental Evaluation 

We showed the recall and precision performance of the 18 retrieval sessaons 
using the 3 different KPS scenarios in Table 7. This table indicates that for a Low 
scenario KPS, we have a very high recall for all queries, a perfect score of 1.0 for all 
queries. However, its precision is very low; it starts at 0.1 to 0.5. This is due to the fact 
that we have stressed coverage. Here we have considered very minimal partial matches 
as well as full matches. In opposite, for a High KPS scenario, we had a high precision 
performance but we lost some recall performance at the same time. This is due to the fact 
that we are have asked the system to look only for full matches. The precision values 
have a perfect score of 1.0 and the recall measurement is in the range of 0.16 to 1.0. 
Balance recall and precision is achieved using the Medium KPS scenario. From Table 7, 
we see that the recall values stays constant at 1.0 while the precision varies from 0.66 to 
1.0. This is a better selection criterion since it balances between our recall and precision 
measurements. 

In comparing with a study by [14], for precision, we see that the High KPS 

scenario is in the same class with Faceted approach*^. However, it recall performance is 
outperformed by Faceted approach by a small factor of 0.15 on the low side. Our 
Medium KPS has a better recall performance but has a lower precision than the Faceted 
approach. It is about the same class as the Attribute-Value approach. 


16.Faceted approach is ranked highest in precision among Attribute-value, Enumerated, Keyword. 
Note here that we are not considering the analysis of variance for precision as stated in [14]. 
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We note that the study in [14] is a much bigger scale evaluation. However, we 
can see that this study gives us some indications about the performance of the system as 
well as how our selection criteria can effect the precision and recall measurement of the 
system. In addition to this, we also conclude that, through a conservative selection 
criterion (Medium KPS scenario), we can possibly obtain a balanced recall and precision 
retrieval which improve on the recall and precision obtainable by other search 
techniques. This is due to the fact that we allow a user to have control over the search 
process through the selection criterion option. This also fits to our assumption that search 
can be made an iterative process. 
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IX. SUMMARY AND SUGGESTIONS FOR FUTURE 

RESEARCH 

A. INTRODUCTION 

This chapter summarizes the contents of the dissertation, identifying those areas 
that are contributions to the state of the art, and then offers suggestions for future research. 
Section B contains the dissertation summary. Section C discusses system modifications to 
improve its performance. Section D describes the system extensions and suggestions for 
future research. Section E describe changes to the implementation required to get a pro¬ 
duction quality realization of the method that can be integrated with the CAPS system. 

B. DISSERTATION SUMMARY 

This dissertation has described in detail a technique for retrieving reusable soft¬ 
ware components from a software library using a partial specification. A prototype has 
been built with an intention to improve and port it to the Computer Aided Prototyping 
System (CAPS). The goal of CAPS is to provide the software engineer with an environ¬ 
ment to support rapid prototyping for hard real embedded systems. CAPS uses a prototype 
language PSDL to specify both prototypes and production software. The retrieval reusable 
components can help to improve the prototyping process and produce quality code. 

In our approach, the search for software components is organized as a series of 
increasingly stringent filters on software library components. We first filter components 
by comparing pre-computed syntactic profiles of components with the profile of the query. 
The inclusion relation from a Hasse diagram has been used to facilitate this retrieval pro¬ 
cess. The result of this process is a set of candidate components with their Profile and Key- 
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wordMatchRatio. Secondly, we filter these components by seeking to find type-consistent 
translations from the query signature to the component signatures. This is accomplished 
by signature matching, which looks for maps that translate the sort and operation symbols 
of the query into corresponding sort and symbols of candidate components. This matching 
process also uses profiles to reduce the computational effort required. Signature matches 
calculated can be partial, in that only part of the functionality the user seeks may actually 
be available. Third, the semantic filtering ranks components by how well they satisfy the 
ground equations in the query and eliminates the components that do not satisfy any of the 
ground equations. In this process, equations that are logical consequences of the query 
specification are translated through the signature matches into equations whose validity is 
checked with respect to the candidate specifications. Finally, the candidates in the choice 
set are ranked according to their likelihood of success. The final output represents this 
choice set as well as how it is computed. Invalid information is also reported to help a user 
to reformulate a new query if needed. This whole process can be made iterative. 

This dissertation makes contributions to the state of the art in reusable software 
component retrieval. 

• A theory of query by partial specification through a multi-level search of soft¬ 
ware components by comparing between specifications based on syntactic 
(profile/keyword, signature matching) and semantic information. 

• A new method, algorithms, and corresponding implementation that optimizes 
the signature matching process (for full and partial matches) to produce a set of 
optimized maps (no duplication or sub-maps). This method is also considers 
subsort relation for handling component matching. 

• A new model for organization of a software library using a Hasse diagram to 
facilitate of the retrieval process. This model can play an important role in sup¬ 
porting the cataloging of components through semi-automation. 
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• A new multi-level ranked scheme to order components in terms of their close¬ 
ness to the user query. 

• A new and unique way for classification of program operations in terms of the 
profiles for approximate signature matching and classification of software 
components. 

• Evidence that a large scale reuse is feasible, avoiding the limitations of infor¬ 
mal methods (i .e using keywords or facets) and complexity of formal methods 
(having the user query using a complete formal specification). The system pro¬ 
posed also can handle both non-generic as well as generic software compo¬ 
nents. This is a real practical requirement for a retrieval system. The system 
can also provide useful data to help the user to formulate a new query if 
needed. 

• The ideas proposed in this dissertation may have implications for software test¬ 
ing. In particular, the techniques for generating test cases to be used in match¬ 
ing queries could also be used to test the correctness of code that is supposed to 
implement a module. 

C. SYSTEM MODIFICATIONS TO ENHANCE PERFORMANCE 

This section suggests the modifications that would help the system to improve its 
performance. These modifications should be relative easy to implement, and they require 
only simple verifications. 

1. User Interface 

As a prototype, the current prototype system has a very limited user interface capa¬ 
bility. It would be nice to develop a front end graphical user interface for the system. On 
top of this, a syntax directed editor can be used to assist a user with the query formulation 
process. This would also assure that the partial specification entered by a user is syntacti¬ 
cally correct before the retrieval process is started. The output of the prototype should also 
be improved and automated so that the user can view the desired retrieval information and 
the selected components with ease. Finally, it would be a good idea to store previous que- 
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ries in a database so that a user can reuse them in the future. The verification here is to 
check for the system for the ability to input query via menu. The output of the retrieval 
process can also be used to verify for input data. 

2. Incremental Retrieval of Software Components 

The current prototype can work with a single selected block of signature maps (85 
maps) per execution. For a production system, it should allow a user to backtrack or go 
forward to any particular block of maps desired. The same approach should be the used for 
allowing the user to view components with any KPS value. This option would add more 
flexibility for a user in controlling the search process. To verify this process, we can eval¬ 
uate the output of the retrieval process such as the map ids and the Keyword, Profile, and 
Signature Match Ratios, and ComponentRank of the retrieved components. 

3. Loading of OBJ3 Environment 

For the semantic filtering process, the current implementation load OBJ3 environ¬ 
ment every time a component is being checked for its ground equation. This loading can 
take some additional time off from the retrieval speed. For the purpose of efficiency, this 
OBJ3 environment should be loaded only one time during the retrieval process. To verify 
this, we can look at the OBJ3 process id and status as it executes. The Unix command “ps” 
would allow us to do that. 

D. SUGGESTIONS FOR FUTURE RESEARCH 

1. Environment for Evaluation of Test Cases in Queries 

The current prototype uses OBJ3 ‘s term rewriting capability to evaluate the 
ground equations. A suggestion for future research is to compare the cost these test cases 
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to the cost of directly in compiled code for the component implementations. Since the 
number of test cases per query is likely to be small and since new code will have to be 
generated, compiled, and loaded to invoke the components chosen by semantic matching, 
this overhead could overwhelm the speed advantage of compiled code over term rewrit¬ 
ing, especially since one call to OBJ3 could handle a batch of several specifications with 
their reductions. The costs involved here should be checked experimentally. The differ¬ 
ence between these approaches should be measured to help decide if it is worth the effort 
of associating formal specifications with each component in the software base. 

2. The Choice for Rank Functions 

So far all ground equations are assumed to have equal importance. Some equations 
that may be more significant to a user than the others. For such situations, we can attach 
weights reflecting the relative importance of different equations. This should be evaluated 
experimentally. The proper weighting of the importance of the number of equations that 
match for a given operation relative to the number of operations that are supported by a 
given number of test cases should also be further explored. Using the relation = in section 
4.4 means that some operation matches will be better that others; the definition of match 
ratio of the signature match could be modified to take account of this, and then it would be 
interesting to see if this helps with retrieval. 

3. Possible Improvements for the Signature Matching Algorithm 

The current SignatureMatching algorithm can match a query constant to a compo¬ 
nent constant as long as their sort assignment is allowable. In the experiment components, 
there are two kind of constants. They are generator constants and exception error con- 


91 


stants. During the course of testing and evaluation of the SignatureMatching algorithm, 
many useless maps that were created because the system tries to match a query generator 
constant with an exception constant from the component or vice versa. This kind of 
matching is unrealistic, and it should not be included in any signature maps. We should 
only match query generator constants with the generator constants from the component. 
The same would be true for exception error constants. One possible way to improve the 
matching process is to have a user explicitly declare exception constants in the specifica¬ 
tion (the Ada programming language also requires users to declare exceptions in the spec¬ 
ifications). Given this information, the SignatureMatching algorithms could know the 
difference between the two and would not try to cross-assign them with one another. 

The second possible improvement is to order the query and component operations 
in some fashion using their profile values. From here the SignatureMatching process can 
sequentially step through these ordered operations and match them. This would should 
reduce the number of combinations to be checked. We should note here that this matching 
process may not be linear due to multiple operations with same profile involved from the 
query and component (i.e., duplication of operation’s profiles in the query but not in the 
component). This needs experimentally evaluated and compared with the current 
approach. 

4. Experimentation with other Components from other Libraries 

The experiments completed so far indicate that it works well with small subset of 
the Booch library components, namely Data Structure components. The author believes 
that additional testing should be performed in a laiger setting and include more variety of 
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components from a different domains such as navigation, business, and mathematical 
components. Using this setting, more available data can be collected and compiled for 
recall and precision measurements. 

5. Exploring other Speciflcation Languages 

In addition to OBJ3, it would be useful to explore using other languages to repre¬ 
sent the formal specifications. For example, it would be interesting to see if the techniques 
suggested here would work for FOOPS, which is an extension of OBJ that handles states, 
and for Eqlog, which extends OBJ with some features of logic programming. It would be 
interesting to assess the value of Eqlog for matching, and to explore the trade-offs between 
expressive power and computational requirements. Eqlog has been implemented by Dia- 
conescu [1] as an extension of the OBJ3 interpreter. 

E. SUGGESTION CHANGES TO GET A PRODUCTION QUALITY 

To get a production quality of the current implementation, the following points are 
recommended; 

• Replace integer constants in Gldef a and Swbdef a with enumeration types for 
ease of maintenance and debugging purposes. Replace string variables from 
bounded size to unbound size. 

• Incorporate the actual library system to replace the simulated Hasse diagram 
modules swb.a and swbdef a. 

• Incorporate the user interface procedure Getquery with a more friendly graphi¬ 
cal user interface module. Also replace the module SortDisplayResult to output 
text data in a friendly graphical form. This would provide a better interaction 
between the system and user. 

• Re-implement the current design so that OBJ3 environment can be load only 
once for each query session. This would save some execution time. 

• The MBN option could be removed. In this way the system would require to 
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search through all possible maps for the best possible maps instead stopping at 
current limit which is 85 maps. This would be a better solution to current 
implementation since a user is provide less input with the query. 

• Include an option to allow a user to view all the signature maps from the log 
files (component name with extension “tc”) for evaluation if he/she desires so. 
These signature maps can be also incorporated as inputs to a wrapper program 
for the CAPS prototype. 


94 



REFERENCES 


[1] Razvan Diaconescu. Category-Based Operational Semantics o/Equational Logic Pro- 

gramming. Ph.D. thesis. Programming Research Group, Oxford University 1994. 

[2] Scott J. Dolgoff. Automated interface for retrieving reusable software components, 

1992. Master’s thesis. Naval Postgraduate School, Monterey, California. 

[3] G. Fischer, Scott Henninger, and D. Redmiles. Cognitive tools for locating and com¬ 

prehending software objects for rescue. In Proceedings, 13the International Confer¬ 
ence on Software Engineering, May 1991. 

[4] William B. Frakes and Thomas P. Pole. An empirical study of representation methods 

for reusable software components. IEEE Transactions on Software Engineering, 
20(8):617-630, August 1994. 

[5] William B. Frake and Isoda Sadahiro. Success factors for systematic reuse. ZEEE Soft¬ 

ware, pages 15-19, September 1994. 

[6] Kokichi Futatsugi, Joseph Goguen, Jean-pierre Jouannaud, and Jose Meseguer. Princi¬ 

ples of OBJ2. In Brian Reid, editor, Proceedings, Twelfth ACM Symposium on Prin¬ 
ciples of Programming Languages, pages 52-66. Association for Computing 
Machinery, 1985. 

[7] Joseph Goguen. Suggestions for using and organizing libraries in software develop¬ 

ment. In Steven Kartashev and Svetlana Kartashev, editors. Proceedings, First Inter¬ 
national Conference on Supercomputing Systems, pages 349-360, IEEE Computer 
Society, 1985. Also in Supercomputing Systems, Steven and Svetlana Kartashev, 
Eds., Elsevier, 1986. 

[8] Joseph Gc^en and Razvan Diaconescu. A short Oxford survey of order sorted alge¬ 

bra. Bullentin of the European Association for Theoretical computer Science, 
48:121-133, October 1992. Guest column in the ‘Albegraic Specification Column’. 
Also in Current Trends in Theoretical Computer Science: Essays and Tutorials, 
World Scientific, 1993, pages 209-221. 

[9] Joseph Goguen and Razvan Diaconescu. Towards an algebraic semantics for the object 

paradigm. In Hartmut Ehrig and Fernando Orejas, editors. Proceedings, Tenth Work¬ 
shop on Abstract Data Types, pages 1-29. Springer, 1994. Lecture Notes in Computer 
Science, Volume 785. 

[10] Joseph Goguen, Claude Kirchner, Helene Kirchner, Aristide Megrelis, and Jose 
Meseguer. An introduction to OJB3. In Jean-Pierre Jouannaud and Stephane Kaplan, 


95 



editors. Proceedings Conference on Conditional Term Rewriting, pages 258-263. 
Pringer, 1988. Lecture Notes inn Computer Science, Volume 308. 

[11] Joseph Goguen and Grant Malcolm. Proof of correctness of object representation. In 
A., William Roscoe, editor, A Classical Mind: Essays in Honour of C.A.K Hoare, 
pages 119-142. Prentice-Hall, 1994. 

[12] Joseph Goguen and Jose Meseguer. Universal realization, persistent interconnection 
and implementation of abstract modules. In M. Neilsen and E.M. Schmidt, editors. 
Proceedings, 9th International Conference in Automata, Languages and Program¬ 
ming, pages 265-281. Springer, 1982. Lecture Notes in Computer Science, Volume 
140. 

[13] Joseph Goguen and Jose Meseguer. Order-sorted algebra I; Equational deduction for 
multiple inherirtance, overloading, exceptions and partial operations. Theoretical 
Computer Science, 105(2):217-273, 1992. Also Programming Research Group Tech¬ 
nical Monograph PRG-80, Oxford University, December 1989, and Technical Report 
SRI-CSL-89-10, SRI International, Computer Science Lab, July 1989; originally 
given as lecture at Seminar on Types, Camegie-Mellon University, June 1983; many 
draft versions exist, from as early as 1985. 

[14] Joseph Goguen and Jose Meseguer. Software component search. Technical report, 
SRI International, Computer Science lab, September 1994. 

[15] Joseph Goguen, James Thatcher, and Eric Wagner. An initial algebra approach to the 
specificating, correctness and implementation of abstract data types. Technical 
Report RC 6487, IBM T.J. Watson Research Center, October 1976. In Current 
Trends in Programming Methodology, IV, Reymond Yeh, editor, Prentice-Hall, 1978, 
pages 80-149. 

[16] Joseph Goguen, Timothy Winkler, Jose Meseguer, Kokichi Futatsugi, and Jean-Pierre 
Jouannaud. Introducing OBJ. In Joseph Goguen, editor. Algebraic Specification with 
OBJ: An Introduction with Case Studies. Cambridges, to appear. Also Technical 
Report, SRI International. 

[17] Patrick Hall and Cornelia Boldyreff. Software Engineer’s Reference Book. Butter- 
worth-Heinemann, 1991. 

[18] Scott Henninger. Using iterative refinement to find reusable software. IEEE Software, 
pages 48-59, September 1994. 

[19] Luqi. Normalized specifications for identifying reusable software. In Proceedings of 
the 1987 FallJoint Computer Conference, pages 46-49. IEEE, October 1987. 


96 



[20] Luqi, Valdis Berzins, and Raymond Yeh. A prototyping language for real-time soft¬ 
ware. IEEE Transactions on Software Engineering, 14(10): 1409-1423, 1988. 

[21] Luqi and Yuh Jeng Lee. Towards automated retrieval of reusable software compo¬ 
nents. In Proceedings, AAAI Workshop on Artificial Intelligence and Automated Pro¬ 
gram Understanding, July 1992. 

[22] Luqi and Mohamed Ketabchi. A computer-aided prototyping system. IEEE Software, 
pages 66-72, March 1988. 

[23] Yoshihiro Matsumoto. A software factory: An overall approach to software produc¬ 
tion. In Peter Freeman, editor. Tutorial on Software Reusability, pages 155-178. 
IEEE, 1987. 

[24] Jose Mesguer and Joseph Goguen. Initially, induction and computability. In Maurice 
Nivat and John Reynolds, editors, Albegraic Methods in Semantics, pages 459-541. 
Cambridge, 1985. 

[25] A. Mili, R. Mili, and R. Mittermeir. Storing and retrieving software components. In 
Proceedings 16th International Conference on Software Engineering, pages 15-19, 
1994. 

[26] Joseph Goguen, Doan Nguyen, Jose Meseguer, Luqi, Du Zhang, and Valdis 
Berzins, "Software Component Search", to be published in the special issue of 
the Journal of System Integration, January 1996. 

[27] E. Ostertag, J. Hendler, Rubin Prieto-Diaz, and C. Braun. Computing similarity in a 
reuse library system. ACM Transaction on Software Engineering and Methodology, 
pages 205-228, July 1992. 

[28] Dogan Ozdemir. The design and implementation of a reusable component library and 
a retrieval/integration system, 1992. Master’s thesis, Naval Postgraduate School, 
Monterey, California. 

[29] Andy Podgurski and Lynn Pierce. Retrieving reusable software by sampling behav¬ 
ior. ACM Transactions on Software Engineering and Methodology, 2(3):286-3303, 
1993. 

[30] Rubin Prieto-Diaz. Implementing faceted classification for software roise. Commu¬ 
nication of the ACM, pages 89-97, May 1991. 


97 


[31] Eugene J. Rollins and Jeannette M. Wing. Specifications as search keys for software 
libraries. In Proceedings of the Eighth International Conference on Logic Program¬ 
ming, 1991. 

[32] Robert Steigerwald, Luqi, and John McDowell, CASE tool for reusable software 
component storage and retrieval in rapid prototyping. Information and Software 
Technology, pages 698-705, 1991. 

[33] Robert A. Steigerwald. Reusable Software Component Retrieval via Normalized 
Algebraic Specifications. Ph.D. thesis, Naval Postgraduate School, 1991. 

[34] Amy Moormann Zaremski and Jeannette M. Wing. Signature matching, a tool for 
using software libraries. In Proceedings, ACM Symposium on Foundations of Soft¬ 
ware Engineering, 1993. To appear. Transactions on Software Engineering and 
Methodology. 

[35] Amy Moormann Zaremski and Jeannette M. Wing. Specification matching of soft¬ 
ware components. Technical Report CMU-CS-95-127, School of Computer Science, 
Camegie-Mellon University, 1995. 

[36] Ruey-Wen Hong. User interface and database design for software database of the 
Computer Aided Prototyping System (CAPS), 1996. Master’s thesis. Naval Post¬ 
graduate School, Monterey, California. 

[37] Tuan Nguyen. Populating the software database for the Computer Aided Prototyping 
System (CAPS), 1996. Master’s thesis. Naval Postgraduate School, Monterey, Cali¬ 
fornia. 

[38] J. Tunner and T. McCluskey. The construction fo Formal Specification. An introduc¬ 
tion to the Model-Based and Algebraic Specification. 

[39] Grady Booch. Software components with Ada : structures, tools, and subsystems. 
Benjamin/Cummings Pub. Co., 1987. 


98 



APPENDIX A - BACKGROUND INFORMATION 

In this chapter we provide some background information and necessary defini¬ 
tions. These materials are not intended as a tutorial, but rather to indicate what the reader 
needs to know in understanding the technical aspects of our work, especially in Chapter 
rv. Interested readers can refer to [10,15,16,17] for more information. 

A. OBJ3 AND ALGEBRAIC SPECIFICATION 

OBJ3 is a functional programming language rigorously based on order sorted logic 
and can be used to describe the syntactic and semantic properties of sequential processes. 
The rigorous semantics of the language also allows specifications to be written as pro¬ 
grams that are declarative in style and mirror the structure of an algebraic specification. 
This property makes it possible for OBJ3 to be used as a theorem prover for validating and 
implementing algebraic specifications. Finally, OBJ3 supports parameterized program¬ 
ming which is one of the powerful features that support our work in handling generic 
modules. 

In OBJ3, an algebraic specification for objects consists of two parts: a signature 
and a set of axioms. The signature defines the sorts (or types) being specified, the opera¬ 
tion symbols, and their functionality in an object. It is denoted as (S, X) where S and X 
are a sort set and an operation symbol set, respectively. The axioms are expressed as equa¬ 
tions describing the semantics (or behavior) of an object. 

B, GROUND EQUATION 

In our user query specification, an equation which contains no variables is referred 
to as a ground equation. It illustrates an example of an object’s behavior by describing 
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how the operations are interacted with one another using only appropriate ground terms, 
we assume that the set of ground equations in the query has distinct left-hand sides and is 
complete, in the sense of being terminating and Church-Rosser; it does not need to be 
“complete” in the sense of completely describing the desired component. 

C. TERM REWRITING 

In order that a specification can be executed to determine that the intended proper¬ 
ties follow the stated axioms, a technique called Term Rewriting is used. In term rewriting, 
each axiom is interpreted as a left-to-right rewrite rule that states the left hand side (LHS) 
can be rewritten to its corresponding right hand side (RHS). Given terms t^, tj, and tjj, a set 

'R of rewrite rules is Church-Rosser if whenever 
t and =>* t 

* 7 * * 

then there is a term tj such that t. =>* and , where => * denotes suc¬ 

cessive application of rewrite rules. T is terminating if there is no infinite chain of rewrite 
applications. 'R is canonical if it is Church-Rosser and terminating. Given term t and t, if 
(/ => * t') and f can not be further reduced through any of rewrite rules, then f is 
referred to as the normal form oft. For canonical specification, each ground term has a 
unique normal form, called its canonical form. Term rewriting is implemented in OBJ3 in 
terms of a feature called “Reduce” that reduces an expression to its normal form. 

D. OPERATIONS 

Let A be a nonempty set, then the n-ary operation op is a function from A to A 
and is written op: A" -4 A. A nullary operation op; ^ A, corresponds to a constant 
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value that is a member of the set A while a unary operation is a function from A into A, 
that is op; A -> A. Operations are also referred to as Functions. [38] 

E. ACCESSOR AND CONTRUCTOR OPERATIONS 

An operation whose range sort that is not a principle sort is defined to be an acces¬ 
sor operator. For example, in our stack example, the Top operation is an accessor since it 
does not return a result of sort stack (the main sort). An operation whose range sort that is 
a principal sort is defined to be a constructor operation. The values of an abstract data type 
are built up using constructor operations. Constructors can further break down into atomic 
and nonatomic operators. For example, in a Stack component, operations create and push 
are atomic constructors while the pop operator is a nonatomic constructor operator. The 
rationale here is that whatever the value constructed by the pop can also be performed by 
using push and create operators. 
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APPENDIX B - OBJ3 COMPONENTS 


This appendix contains the OBJ3 source code for the twelve Booch data structure 
Components. They are as follows: 

3|( 3|(1♦ 4c 4c :4c ]|C jK * * 3(c 3fc t * :(C # * * 9|( 3ft * ]fc J|C J|c 3|C 3|C ]|c 4e afc ]|C 4e Jte 4c 

*** This is a listl obj3 (Generic Version) 

*** Keywords: Booch, Data-Structure, List 

*** Function: To perform list data structure operations. 

*** Component Histoiy: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 

4c 4c 4c 4e 4c 4e 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4e 4e 3|c 4c 4c 4c 4c 4c 4e 4c 4c 4c 4e 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4e 4c 4c 4c 

obj list! [X :: TRIV] is sort List. 
protecting NAT. 
op nil: -> List. 
op cons : Elt List -> List. 
op headof: List -> Elt. 
op tailof: List -> List. 
op clear: List -> List. 
op clearhead : List -> List. 
op contains : List Elt -> Bool. 
op lengthof: List -> Nat. 
op sethead : Elt List -> List. 
op isnull: List -> Bool. 
op isequal: List List -> Bool. 
op listerror: «> List. 
op elterror : -> Elt. 
op copy : List List -> List. 

var I, J : Elt. 
var L : List. 
var N1 : List. 

eq copy(nil jiil) = nil. 
eq copy(L,nil) = L . 
eq copy (nil X) = nil. 

eq copy(cons(J,L),cons(I,Nl)) = cons(J,copy(L,Nl)). 
eq lengthof(nil) = 0 . 

eq lengthof(cons(I,L)) = 1 + lengthof(L) . 
eq isequal(nil,nil) = true . 

eq isequal(L,nil) = if not lengthof(L) == 0 and Iengthof(nil) == 0 
then false else true fi. 

eq isequal(nil,Nl) = if lengthof(nil) == 0 and not lengthof(Nl) = 0 
then false else true fi. 

eq isequal(cons(J,L),cons(I,Nl)) = if J == I and isequaI(L,Nl) 
then true else false fi. 
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eq clear(L) = nil. 

eq clearhead(nil) = nil. 
eq cIearhead(cons(I,L)) = L . 

eq isnull(L) = if lengthof(L) = 0 then true else false fi. 

eq headof(nil) = elterror . 
eq headof(cons(I,L)) = I. 

eq tailof(nil) = nil. 
eq tailof(cons(I,L)) = L . 

eq sethead(I^il) = listerror. 
eq sethead(I,L) == cons(I,clearhead(L)). 

eq contains(nil,I) = false . 

eq contains(cons(J,L),I) = if J == I then true else contains(L,I) fi, 
endo 

*** This is a list! obj3 (List of Natural number) 

*** Keywords: Booch, Data-Structure, List 

*** Function: To perform list data structure operations. 

*** Component History: Components from CS4520 Project. 

♦♦♦ Modify syntax to work with SCS prototpe. 

obj list is sort List. 
protecting NAT . 
op nil: -> List. 
op cons : Nat List -> List. 
op headof: List -> Nat. 
op tailof: List -> List. 
op clear : List -> List. 
op clearhead : List -> List. 
op contains : List Nat -> Bool. 
op lengthof: List -> Nat. 
op sethead : Nat List -> List. 
op isnull: List -> Bool. 
op isequal: List List -> Bool. 
op listerror : -> List. 
op elterror : -> Nat. 
op copy : List List -> List. 

var I, J : Nat. 
var L : List. 
var N1: List. 

eq copy(nil,nil) = nil. 
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eq copy(L,nil) = L . 
eqcopy(nil,L) = nil. 

eq copy(cons(J,L),cons(I,Nl)) = cons(J,copy(L,Nl)). 
eq lengthof(nil) = 0 . 

eq lengthof(cons(I,L)) = 1 + lengthof(L). 
eq isequal(nil,nil) = true . 

eq isequal(L,nil) = if not lengthof(L) = 0 and lengthof(nil) == 0 
then false else true fi. 

eq isequal(nihNl) = if lengthof(nil) == 0 and not lengthof(Nl) == 0 
then false else true fi. 

eq isequal(cons(J4.),cons(I,Nl)) = if J == I and isequal(L,Nl) 
then true else false fi. 

eq clear(L) = nil. 

eq clearhead(nil) = nil. 
eq clearhead(cons(I,L)) = L . 

eq isnull(L) = if lengthof{L) = 0 then true else false fi. 

eq headof(nil) = elterror . 
eq headof(cons(I,L)) = I ^ 

eq tailof(nil) = nil. 
eq tailof(cons(I,L)) = L . 

eq sethead(I,nil) = listerror. 
eq sethead(I,L) = cons(I,clearhead(L)). 

eq contains(nil,l) = false . 

eq contains(cons(J,L)J) = if J = 1 then true else contains(L,I) fi. 
endo 

:|c# ]|e 3tc )|C ]|e J(e t ic ♦ * ♦ ♦ :(c 3|C« ^ % i(c 3fc 4c t * 3|c * ♦ 9|C 3ie 4c :|c «3|e t 9f( * * 3|c * « He :tc ♦ * ♦ ♦ ♦ 

js g (Binary Tree Data structure version 1) 

*** Keywords: Booch, Data-Structure, Binaiy-Tree 

♦♦♦ Function: To perform binary tree data structure operations. 

*** Component History; Components from CS4520 Project. 

Modify syntax to work with SCS prototpe. 

4eHeHcHcHcHcHcHcHcHcHcHcHcHeHcHcHcHcHtHcHcHeHcH(HcHcHcHcHcHeHcHcHcHcHcHcHcHcHcHcHeHcHcHcH(HcHcHcHcHcHeHcHeHcHcHcHeH(HeHcHcHcHeHeHeH(HcHcHcHeHcHe 

object bint 1 pc :: TRIV] is sort Bintree . 
protecting NAT . 
protecting INT. 
op empty : -> Bintree . 
op left : Bintree -> Bintree . 
op right : Bintree -> Bintree . 
op isempty : Bintree -> Bool. 
op node : Bintree -> Elt . 
op isin : Elt Bintree -> Bool, 
op naterror: -> Elt. 
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op make : Elt Bintree Bintree -> Bintree . 
op max : Nat Nat -> Nat. 
op depth : Bintree -> Nat . 
op height; Bintree -> Nat. 

var m : Elt. 
var l,r : Bintree . 
var n : Elt. 
var i: Nat. 
var j : Nat. 

eq left(empty) = empty . 
eq left(make(n,l,r)) = 1. 

eq right(empty) = empty . 
eq right(make(n,l,r)) = r, 

eq node(empty) = naterror. 
eq node(make(n,l,r)) = n . 

eq isempty(empty) = true . 
eq isempty(make(n,l,r)) = false . 

eq isin(n,empty) = false . 

eq isin(m,make(n,l,r)) = if n == m then true else isin(m,l) or isin(m,r) fi. 
eq max(i j) = if i > j then i else j fi. 
eq depth(empty) = 0 . 

eq depth(make(n,kr)) = 1 + max(depth(l), depth(r)). 
eq height(make(n,kr)) = depth(make(n,l,r)) - 1 . 
endo 

♦♦♦ This is a bint2 obj3 (Binary Tree Data structure version 2) 

♦♦♦ Keywords: Booch, Data-Structure, Binary-Tree 

*** Function: To perform binary tree data structure operations. 

*** Component History: Components from CS4520 Project. 

♦** Modify syntax to work with SCS prototpe. 

obj bint2[X :: TRIV] is 
sorts Tree Child Node . 
protecting NAT. 
subsoit Node < Tree . 

op null -> Tree . 

op left: •> Child . 

op right -> Child . 

op node : Elt Tree Tree -> Tree . 
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op copy.T2 : Tree Tree -> Tree . 
op clear. T : Tree -> Tree . 
op construct.T : Elt Tree Child -> Tree . 
op setitem.T : Elt Tree -> Tree . 
op swapchild.Tl : Child Tree Tree -> Tree . 
op swapchild.T3 ; Child Tree Tree -> Tree . 
op isequal : Tree Tree -> Bool. 
op isnull : Tree -> Bool. 
op itemof: Tree -> Elt. 
op childof: Child Tree -> Tree . 
op treeisnull : -> Tree . 
op treeisnull : -> Elt. 

varTTl T2T3T4:Tree. 
varC Cl C2: Child. 
varIIlI2:Elt, 

eqcopy.T2(Tl,T2) = Tl . 
eq clear. T(T) = null. 

eq construct.T(I,T,C) = if C == right then node(I,null,T) 
else node(I,T,null) fi. 
eq setitem.T(I,null) = treeisnull. 
eq setitem.T(I2,node(IlJl,T2)) = node(I2,Tl,T2). 
eq swapchild.Tl(C,node(I,Tl,T2),T3) = 

if C == left then node(I,T3,T2) 
else node(I,Tl,T3)fi. 

eq swafx:hild.T3(C,node(I,TlJ2),T3) = if C == left then T1 

else T2 fi. 

eq isequal(Tl,T2) = if T1 == T2 then true else false fi. 
eq isnuil(T) = if T == null then true else false fi. 
eq itemof(null) = treeisnull. 
eq itemof(node(I,Tl,T2)) = I. 
eq childof(C,null) = treeisnull. 

eq childof(C,node(I,TlJ2)) = if C == left then T1 else T2 fi. 
endo 

:4t 3|c 9fe 3|t :4c ifi 4c ^ ^ :|c ♦♦♦♦♦♦ 3|c ♦♦ It Ic ]|c * aft 4c ic 3|e ♦ )|t j|c :(e 9|c # 4e # 3|( 3|e 4c 

*** This is a deque obj3 (Deque Data structure) 

♦4c* Keywords: Booch, Data-Structure, Deque 

♦** Function: To perform deque data structure operations. 

*♦* Component History: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 

4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c * 4c 4c 4c 4c 4c * 4c 4c * 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( ♦♦♦ 4c ♦ 4c 4c 4c 4c 4c 4( ♦♦ 4c 4c 4c 4c * 4c 4c 

obj LOCATION is 
sort Location. 

ops Front Back : -> Location . 
endo 

obj deque[X :: TRIV] is 
sort Deque. 


107 



*** Import predefined types 
protecting LOCATION. 
protecting NAT . 

*** Generator 
op empty : -> Deque . 

*** Other constructors/properties 
op copy : Deque Deque -> Deque . 
op clear : Deque -> Deque . 
op add : Elt Location Deque -> Deque . 
op pop : Location Deque -> Deque . 
op isequal : Deque Deque -> Bool. 
op lengthof: Deque -> Nat. 
op isempty : Deque -> Bool. 
op frontof: Deque -> Elt. 
op backof: Deque -> Elt. 

*** Exception 
op underflow : -> Deque . 
op underflow : -> Elt. 

*** Variable declarations 
var D D2 : Deque . 
var L ; Location . 
var E : Elt. 

Equations 

eq copy(empty,D) == empty . 

eq copy(add(E,Front,D),D2) == add(E,Front,copy(D,D2)). 
eq clear(D) = empty . 

eq add(E,Back,D) = if D == empty then add(E,Front,empty) else 
add(frontof(D),Front,add(E,Back,pop(Front,D))) fi. 
eq pop(L,empty) = underflow . 
eq pop(Front,add(E,Front,D)) = D . 
eq pop(Back,add(E,Front,D)) = if D == empty then D else 
add(E,Front,pop(Back,D)) fi. 

eq isequal(D,D2) = if D == D2 then true else false fi. 

eq lengthof(empty) = 0 . 
eq lengthof(add(E,L,D)) = 1 + lengthof(D). 

eq isempty (D) = if D == empty then true else false fi. 

eq frontof(empty) = underflow . 
eq frontof(add(E,Front,D)) = E . 

eq backof(empty) = underflow . 


108 



eq backof(add(E,Front,D)) = if D === empty then E else 
backof(pop(Front,D)) fi. 


endo 

♦ *♦:!(♦♦*** ***********j»c**j|c*j|c****:|c^*:|(*:fcj|c***jlc**Hc>|c*)|eJ|c>tc********J(t*****%******** 

*** This is a Set obj3 (Set Data structure) 

*** Keywords: Booch, Data-Structure, Set 

*** Function: To perform Set data structure operations. 

*** Component History: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 


obj set[X :: TRIV] is sort Set. 
protecting NAT . 

*** basic set operations 

♦** constructors 


op create 
op clear 
op copy 
op add 
op remove 
op union 


Set. 

: Set -> Set. 

: Set Set -> Set. 

: Elt Set -> Set. 

: Elt Set -> Set. 
Set Set -> Set 


op intersection : Set Set -> Set 


*** assessors 


op cardinality : Set -> Nat. 
op isequal : Set Set -> Bool. 
op isempty : Set -> Bool. 
op memberof : Elt Set -> Bool 
op subsetof : Set Set -> Bool. 
op prosubsetof : Set Set -> Bool 

*** exception 
op seterror : -> Set. 
variables declaration 


var S SI S2 S3 S4 : Set. 
varEEl E2 : Elt. 


*** axioms 
eq clear(S) = create . 
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eq cardinality(create) = 0 . 

eq cardinality(add(E,S)) = if meniberof(E,S) then cardinality(S) else 1 + cardinality(S) fi. 
eq reniove(E,create) = seterror . 

eq remove(E,add{El,Sl)) = if E == El then SI else union(add(El,create),remove(E,Sl)) fi . 
eq subsetof(create,Sl) = true . 

*** eq subsetof(add(El,create),add(E2,create)) = if El -= E2 then true else false fi . 

eq subsetof(add(E 1 ,S 1 ),add(E2,S2)) = if memberof(El ,add(E2,S2)) then subsetof(Sl ,add(E2,S2)) else 
false fi . 

eq prosubsetof(Sl ,S2) = if subsetof(Sl ,S2) and cardinality (S2) > cardinality(Sl) then true else false fi . 
eq memberof(E,create) = false . 

eq memberof(E,add(El,Sl)) = if E = El then true else meniberof(E,Sl) fi. 
eq isequal(create,create) = true . 

eq isequal(add(E,Sl),add(E,S2)) = if SI = S2 then true else false fi . 

eq copy(Sl,S2) = SI . 

eq isempty (create) = true . 
eq isempty(add(E,Sl)) = false . 

eq union(create,S) = S . 
eq union(S,create) = S . 

eq union(add(El,Sl),S2) = if memberof(El,S2) then union(Sl,S2) else add(El,union(Sl,S2)) fi. 

eq intersection(create,S) = create . 
eq intersection(S,create) = create . 

eq intersection(add(El,Sl),S2) = if memberof(El,S2) then add(El,intersection(Sl,S2)) else 
intersection(Sl,S2) fi . 

endo 
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♦ ****♦*♦♦*♦♦* JfC%3ft*j(c*>|c4e*3|C3(C>|t*:tC3)C*3(C3(tjK*j(C3(t3|C3|tJ|C***j|C3|t>|C5*C ♦♦♦♦♦♦♦♦♦♦♦♦ jJt3tC* 

*** This is a bag obj3 (bag Data structure) 

*** Keywords: Booch, Data-Structure, Bag 

*** Function: To perform bag data structure operations. 

*** Component History: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 

♦ t :*c ♦♦*****♦♦ t J«c * JK jfc * 3»c 3*c Jf{ ♦♦♦♦♦♦♦ 3fc * :|c ** J(c 3|e i*t :|c ifc 

obj bag[X :: TRIV] is sort Bag . 
protecting NAT . 

**♦ CONSTUCTORS: 

op copy : Bag Bag -> Bag . 

*** Empty the bag : 
op clear : Bag -> Bag . 

*** Empty bag (constant) 
op empty : -> Bag . 

*** Represents a singlton bag: 
op singlton : Elt -> Bag . 

*** Adds an element to a bag: 
op add : Elt Bag -> Bag . 

*** removes an element from a bag: 
op remove : Elt Bag -> Bag . 

The following 3 ops represent the bags union, intersection, and difference 
*** respectivly: 
op union : Bag Bag ~> Bag . 
op and : Bag Bag -> Bag . 
op diff : Bag Bag -> Bag . 

♦♦♦ 


*** SELECTORS: 

*** The following operation returns the total number of elements in a bag. 
*** More than one occurences of an element is allowed in a bag. 
op lengthof: Bag -> Nat. 

*** The uniqueExtentOf operation returns the number of elements of a bag 
*** counting only one occurence of each element if threre are more than 
*** one (The bag is treated like a set by this operation) : 
op uniqueExtentOf: Bag -> Nat. 

*** The numberof operation gives the number of occurences of a given 
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*** element in the bag: 
op numberof: Elt Bag »> Nat. 

*** The following operations are self explanatory: 
op in : Elt Bag -> Bool. 
op isequal : Bag Bag -> Bool. 
op subset : Bag Bag -> Bool. 
op propersubset: Bag Bag -> Bool. 
op isempty ; Bag -> Bool. 


Exception : 
op bagerror: »> Bag . 


♦** SUPPORTING OPERATIONS : 

*** A bag supporting operation used by most other bag operations: 
op ; Bag Bag -> Bag . 

*** A bag supporting operation used to remove only the first occurence of 
♦♦♦an element that belongs to the bag: 
op removeOne ; Elt Bag -> Bag . 

♦♦♦ 


*♦* VARIABLES: 

varB B1 B2 : Bag . 
varsE El : Elt. 
varX:Elt. 

♦♦♦ 


*** AXIOMS: 

eq empty + B = B . 
eq B + empty = B . 

eqcopy(Bl,B2) = Bl . 

eq clear(B) = empty . 

eq add(X,B) - singlton(X) + B . 
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eq in(X,empty) = false . 
eq in(X,singlton(E)) = (X == E). 

eq in(XXsinglton(E) + B)) = if X = E then true else in(X,B) fi 
eq and(enipty,B) = empty . 

eq and(singlton(E),B) = if in(E3) then singlton(E) else empty fi. 
eq and(singlton(E) + B,B 1) = if in(E,B 1) then 

singlton(E) + and(removeOne(E,B),removeOne(E31)) else and(B,Bl) fi - 
eq union(empty,B) = B . 
eq union(singlton(E),B) = (singlton(E) + B) . 
eq union((singlton(E) -f B),B 1) = singlton(E) + union(B,B 1). 

eq diff(empty3) = empty . 

eq diff(singlton(E),B) = if in(E,B) then empty else singlton(E) fi. 
eq diff((singlton(E) + B),B1) = if numberof(E3) < numberof(E31) then 
diff(B3 1 ) else singlton(E) + diff(B31) fi. 

eq isempty3) = (B == empty). 

eq isequal(empty3) = false . 
eq isequalCB^empty) = false . 

eq isequal(singlton(E),singlton(El)) = if E == El then true else false fi . 
eq isequal(singlton(E)3) = if in(E3) and (lengthof^) == 1) then true 
else false fi. 

eq isequal((singlton(E) + B)31) = if numberof(E,((singlton(E) + B))) == 
numberof(E31) then 

isequal(remove(E3),remove(E31)) else false fi. 

eq subset(empty3) = true . 
eq subset(singlton(E)3) = in(E3) ■ 
eq subset((singlton(E) + B)31) = if 
numberof(E,(singlton(E) + B)) <= numberof(E31) then 
subset(B31) else false fi. 

eq propersubset(B31) = subset(B31) and not isequal(B31) . 

eq lengthof(empty) = 0 . 
eq lengthof(singlton(E)) = 1 . 
eq lengthof((singlton(X) + B)) = 1 + lengthof(B). 

eq remove(E,empty) = bagerror . 

eq remove(E,singlton(El)) = if E = El then empty else singlton(El) fi . 
eq remove(X,singlton(El) + B) = if X == El then 
remove(X,B) else (singlton(E 1) + remove(X,B)) fi. 

eq uniqueExtentOf(empty) = 0 . 
eq uniqueExtentOf(singlton(E)) = 1 . 
eq uniqueExtentOf((singlton(X) + B)) = if in(X3) then 
uniqueExtentOf(B) else 1 + uniqueExtentOf(B) fi 

eq numberTof(E,empty) = 0 . 
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eq numberof(E,singlton(El)) = if E == EI then 1 else 0 fi. 
eqnuniberof(E,(singlton(El) + B)) = if E == El then 
1 + nuniberof(E,B) else numberof(E,B) fi 
endo 

*** This is a Array obj3 (Array Data structure) 

*** Keywords; Booch, Data-Structure, Array 
*♦* Function: To perform Array data structure operations. 
*** Component Histoiy: Components from CS4520 Project. 
*** Modify syntax to work with SCS prototpe. 

♦ ♦♦♦jtc3|C**JtCS|t3|C****3tC5|C3|C3teJ»C 

obj array [X :: TRIV] is sort Array . 
protecting NAT . 
protecting INT. 

*** basic string operations 
*** constructors 
op succ _ : Nat -> Nat. 

op pred _ : Nat -> Nat. 

op unitArray : Elt -> Array . 
op abuttedTo : Array Array -> Array . 

op empty Array -> Array . 

op copy : Array Array -> Array . 
op clear : Array -> Array . 
op delete : Nat Array -> Array . 

*** assessors 

op isEqual : Array Array -> Bool. 
op isEmpty : Array -> Bool 
op componentOf : Nat Array -> Elt. 
op sizeOf : Array -> Nat. 

*** exceptions 
op eltUnderflow : -> Elt. 
op natUnderflow : -> Nat. 
op arrayError : -> Array . 

*** Support Operations 
op headof : Nat Array -> Array . 
op tailof : Nat Array >> Array . 

*** variable declaration 

varsAAlAl : Array , 
varsClC2 : Elt. 
vars I ; Nat. 


*** axioms 
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eq succ 1 = 1+1 . 

eq pred I = if (I > 1) then (I - 1) else natUnderflow fi. 

eq headof(0,A) = A . 
eq headof(I,abuttedTo(Al,A2)) = 
if sizeOf(AI) == I then A1 else array Error fi. 

eq tailof(0,abuttedTo(unitArray(C 1 ),A)) == A . 
eq tailof(l,abutledTo(Al,A2)) = 
if si 2 eOf(Al) == 1 then A2 else array Error fi. 

eq delete(0,abuttedTo(unitArray(Cl),A)) = A . 
eq delete(l,A) = abuttedTo(headof(I,A),tailof(I,A)) • 

eq abuttedTo(abuttedTo(A,AlXA2) = abuttedTo(A,abuttedTo(Al,A2)). 

eqcomponentOf(0,unitArray(Cl)) = Cl . 
eqcomponentOf(0,abuttedTo(unitAiTay(Cl),A)) = Cl . 

eq componentOf(l,abuttedTo(iinitArray(Cl),A)) = 

if 1 > 0 then coniponentOf(pred I,A) else eltUnderflow fi. 

eq sizeOf(unitArray(Cl)) = succ 0 . 
eq sizeOf(abuttedTo(unitArray(Cl),A)) = succ (sizeOf(A)). 

eq copy(empty Array ,A) = empty Array . 

eq copy(Al,A2) = if sizeOf(Al) == sizeOf(A2) then A1 else arrayEnorfi. 
eq clear(A) = empty Array . 

eq isEqual(Al,A2) = if A1 = A2 then true else false fi. 

eq isEmpty(clear(A)) = true . 
eq isEmpty(emptyArray) = true . 
endo 

« ^ t ^ * :te % 4c # ^ :|t :|c 4c # 9(c« « ic ]((](c J|C # ^ t I|c )(C 3|E 4c 4c ^4c 1|C ]|c * 3|t # # * # 

*** This is a ring obj3 (ring Data structure) 

*** Keywords: Booch, Data-Structure, Ring 

*** Function: To perform Ring data structure operations. 

*** Component History: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 

4c 4c 4c 4c ♦ ♦ 4c 4c 4c ♦ ♦ 4( 4t 4c 4( 4( 4( 4c 4e 4e 4c 4c 4e * 4c 4c 4c ♦ 4( ♦ ♦ ♦ ♦ ♦ ♦ 4c * ♦ 4c 4e 4t 4c * * ♦ 4c 4t*4t#4t ♦ ♦ 4( 4t ♦ ♦ 4t 4e 4t 4t4t 4(« ♦ ♦ 4c ♦ 4( 4( ♦ 4t 

obj DIRECTION is 
sort Direction. 

ops Forward Backward : -> Direction . 
endo 

obj ring[X :: TRIV] is 
sorts Ring ERing. 
subsort Ring < ERing . 

*♦* Import predefined type 
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protecting NAT . 
protecting DIRECTION. 

*** Generator 
op empty : -> Ring . 
op : Nat Ring -> ERing . 

op : Nat Ring -> Ring . 

*** op {_,rotateerror} : Nat Ring -> Ring . 

*** Other constructor/properties 
op copy : Ring Ring -> Ring . 
op copy : ERing ERing -> ERing . 
op clear : ERing -> ERing . 
op insert: Elt Ring -> Ring . 
op insert: Elt ERing -> ERing . 
op pop : Ring -> Ring . 
op pop : ERing -> ERing . 
op rotate : Direction Ring -> Ring . 
op rotate : Direction ERing -> ERing . 
op mark : ERing -> ERing . 
op rotatetomark : ERing -> ERing . 
op isequal: ERing ERing -> Bool. 
op extentof: Ring -> Nat. 
op extentof: ERing -> Nat. 
op isempty : ERing -> Bool. 
op topof: Ring -> Elt. 
op topof: ERing -> Elt. 
op atmark : ERing -> Bool. 

*** Exceptions 
op underflow : -> Ring . 
op underflow : -> Elt. 
op rotateerror; -> Ring . 

*** Variable declarations 
var R R2 : Ring . 
var A A2 : ERing . 
var E E2 : Elt. 
var M M2 : Nat. 

*** Equations 

eq {O,underflow} = underflow . 
eq {M,rotateerror} = rotateerror. 

eq copy(empty,R) = empty . 
eq copy(insert(E,R),R2) = insert(E,copy(R,R2)) 

eq copy({M,R},{M2,R2})= {M,copy(R,R2)} . 

eq clear({M,R}) = {0,empty} . 
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eq insert(E,{M,R}) = if R == empty then {0,insert(E,R)} else 
{M + l,insert(E,R)} fi. 

eq pop(empty) = underflow . 
eq pop(insert(E,R)) = R . 

eq pop({M,R}) = if M = 0 then {0,pop(R)} else {p(M),pop(R)} fi . 

eq rotate(Forward,empty) = rolateerror . 
eq rotate(Backward,empty) = rotateerror. 

eq rotate(Forward,insert(EJ^)) = if R == empty then insert(E,empty) 
else insert(topof(R),rotate(Forward,insert(E,pop(R)))) fi . 
eq rotate(Backward,insert(E,R)) = if R = empty then insert(E,empty) 
else insert(topof(rotate(BackwardJl)),insert(E,pop(rotate(Backward,R)))) 
fi. 

eq rotate(Fonvard,{M,R}) = if M — 0 
then {p(extentof(R)),rotate(Forward,R)} else 
{p(M),rotate(Forward,R)} fi. 
eq rotate(Backward,{M,R}) = if M == p(extentof(R)) then 
{0,rotate(Backward,R)} else 
{M + l,rotate(Backward,R)} fi. 

eq maik({M,R}) = {0,R} . 

eq rotatetomark({M,R}) = if M = 0 then {M,R} else 

rotatetomark(rotate(Forward,{M,R})) fi. 

eq isequal(A,A2) = if A == A2 then true else false fi . 

eq extentof(empty) = 0 . 
eq extentof(insert(E,R)) = 1 + extentof(R). 
eq extentof({M,R}) = extentof(R), 

eq isempty({M,R}) = if R = empty then true else false fi. 

eq topof(empty) = underflow . 
eq topof(insert(E,R)) = E . 
eq topof({M,R}) = topof(R). 

eq atmaiic({M,R}) = if M == 0 then true else false fi. 

endo 

«3|c :|e 3tc* :(c Jtc 4c:|e * * ic :tc 3|C 3|C 3|C 3|C :fc :te♦ 3|c :|c t t * * ♦ ♦ Ifc 4c ♦ 3|c j|e * 3|c * 4c 

♦♦♦ jg a Stack obj3 (Stack Data structure, version 1) 

*** Keywords: Booch, Data-Structure,Stack 

*♦* Function: To perform Stack data structure operations. 

*** Component History: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 

4c 4c 4c 4c 4c 4c 4c 4c * ♦ 4c 4c 4c ♦ ♦ 4c 4c ♦ 4c ♦ 4( 4c 4c ♦ * 4c 4c 4c 4c 4c 4c 4e 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( * * * 4c ♦ 4( 4c 4c * 4c * ♦ 4c 4c 4c * 4c ♦ 4e 4c ♦ 4( 4c 4c 3|c 4c 

obj stack 1[X :: TRIV] is sort Stack . 
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protecting NAT. 


*** CONSTUCTORS: 

op create : -> Stack . 
op copy : Stack Stack -> Stack . 
op clear : Stack -> Stack . 
op push : Elt Stack ~> Stack 
op pop : Stack -> Stack . 
op empty : -> Stack . 

SELECTORS; 

op top : Stack -> Elt. 
op depthof: Stack ~> Nat 
op isempty : Stack -> Bool 
op isequal: Stack Stack -> Bool 

♦ ♦♦ •^-r:===r===— 

EXCEPTIONS: 

op StackError : -> Stack . 
op StackError : -> Elt. 

♦ ===============:======== 

*♦* VARIABLES: 

var S SI S2 : Stack . 
varX:Elt. 

====:—============——— 

*** AXIOMS: 

eq clear(S) = empty . 

eq copy(empty,S) = clear(S). 

eq copy(push(X,Sl),S2) = push(X,copy(SLS2)). 

eq top(empty) = StackError 

eq top(clear(S)) = StackError . 

eq top(push(X,S)) = X . 

eq pop(empty) = StackError. 

eq pop(clear(S)) = StackError . 

eq pop(push(X,S)) = S , 

eq pop(create) = StackError 

eq depthof(empty) = 0 , 

eq depthof(create) = 0 . 
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eq depthof(push(X,S)) = 1 + depthof(S). 

eq isempty(S) = if (S = create) or (S == empty) then true else false fi. 
eq isequal(Sl ,S2) = if SI == S2 then true else false fi. 
endo 

# !(e :|c :fc }|c 4c * IK 3k * >|c * ♦ ic 3(e >|e 9)( ♦ ♦♦♦♦ 4c ♦♦♦ ♦♦♦♦♦♦♦ )|e ifc * ate * 4c 4c ♦♦♦♦ 4t 4e 

*** This is a Stack obj3 (Stack Data structure, version 2) 

*** Keywords: Booch, Data-Structure,Stack 

*** Function: To perform Stack data structure operations. 

*** Component Histoiy: Components from CS4520 Project 
**♦ Modify syntax to work with SCS prototpe. 

4e 4c 4c 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4e 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4c 

obj stack2[X :: TRIV] is sort Stack . 
protecting NAT. 
basic stack operations 
*** constructors 
op create -> Stack . 

op clear : Stack -> Stack . 
op push : Elt Stack -> Stack . 
op pop : Stack -> Stack . 

**♦ assessors 

op top : Stack -> Elt. 
op isempty : Stack -> Bool. 
op stacksize : Stack -> Nat. 
exception 

op empty error : -> Stack . 

**♦ variables declaration 
var S : Stack . 
varX:Elt. 

*** axioms 
eq clear(S) = create . 
eq top(push(X,S)) = X . 

eq isempty(S) = if S == create then true else false fi . 
eq stacksi 2 e(S) = if S = create then 0 else 1 + stacksize(pqp(S)) fi . 
eq pop(create) = empty error. 
eq pop(push(X,S)) = S . 
endo 


4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4t 4c 4c 4c 4e 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4t 4c 4c 4c 4c 4c 4c 4t 4c 4c 4c 4c 4c 4c 4c 4c ♦ 4c 4c 4c 4c 4c 4c 4c 4e 4c 

*** This is a Queue obj3 (Queue Data structure) 

*** Keywords: Booch, Data“Structure,Queue 

*** Function: To perform Queue data structure operations. 

*** Component History: Components from CS4520 Project. 

*** Modify syntax to work with SCS prototpe. 

4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c ck 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c * 4c 4c 4c 4c 4( 4c 4c 4t 4c 4c 4c 4t 4c 4c 4c 4c 4c 4c 4( 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 

obj queue[X :: TRIV] is sort Queue . 
protecting NAT. 

op empty : -> Queue . 
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op copy-Q2 : Queue Queue -> Queue . 
op clear. Q : Queue -> Queue . 
op add.Q : Elt Queue -> Queue . 
op pop.Q : Queue -> Queue . 
op isequal: Queue Queue -> Bool. 
op lengthof: Queue -> Nat. 
op isempty : Queue -> Bool. 
op frontof: Queue -> Elt. 
op underflow : -> Queue . 
op underflow : -> Elt. 
var Q Q1 Q2 ; Queue . 
var E : Elt. 

eqcopy.Q2(Ql,Q2) = Ql 
eq clear.Q(Q) = empty . 
eq pop.Q(empty) = underflow . 

eq pop.Q(add.Q(E,Q)) = if Q == empty then Q else add.Q(E,pop.Q(Q)) fi. 

eq isequal(Ql,Q2) = if Q1 — Q2 then true else false fi. 

eq lengthof(empty) = 0 . 

eq lengthof(add.Q(E,Q)) = 1 + lengthof(Q). 

eq isempty(Q) = if Q == empty then true else false fi. 

eq frontof(empty) = underflow . 

eq frontof(add.Q(E,Q)) = if Q == empty then E else frontof(Q) fi. 
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APPENDIX C - ADA SOURCE CODE 


— Module Name: gldefa 

— Description: This is the global definition for variables of the 

— software component search prototype 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

Verified as a first prototyped 


Package Global_def is 

Nill: constant := 999; 

Max_maps: constant := 85; 

SortJd_range: constant := 30; 

Void : Constant := 1; 

Unvoid : Constant := 2; 

F : constant := 0; 

T : constant := 1; 

Basic: constant := 1; 

Confined: constant := 2; 

Unconfmed: constant := 3; 

• Constant := 1; 

• Constant := 2; 

Nat_type : Constant :== 3; 

BooMype : Constant := 4; 

Charitype : Constant := 5; 

Eltjype : Constant := 12; 

Unrelated: Constant := 1; 

Related: Constant := 2; 

Bquery_sort: Constant := 10; 

Equery_sort: Constant := 20; 

Type Test_case_str is new string(1..200); 

Type Children_ids type is array (1..3) of Natural; 

Type Parentjds_type is array (1 ..3) of Natural; 

Type Ovl type is array (1..25) of Natural; 

Type Svl^type is array (1 ..25) of Natural; 

Type Lopcjype is array (1..25) of Boolean; 

Type Lds_type is array (1..25) of Boolean; 

Type SymboI_name is new string(I ..20); 

Type Sort_type is anray (1..7) of Natural; 

Type Matrix is array (Positive range o,Positive range o) of Natural; 
Type Sort Rank is 
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Record 

MaxoverallRank : Float; 

ModuleName : Symbol_name; 

SelSemanticRank : Float; 

SelSignatureRank : Float; 

SelKeywordRank ; Float; 

SelProfileRank : Float; 

Mapnum: Natural; 

End Record; 

Type Asort_Array is array(l.. 12) of Sort_rank; 

Type Testcase_Status_type is 
Record 

Complete : Boolean; 

Mul_value: Float; 

Top function: Natural; 

Translate : Boolean; 

End Record; 

Type Testcases_status_types is array(1..5) of Testcase_status_type; 

Type Testequation_type is 
Record 

evalue: Test case str; 

End Record; 

Type Testequations_types is array(1..5) of Testequation_type; 

Type A sort table type is 
Record 

Sort_id: Natural; 

Sort_symbol: Symbol_name; 

Main_sort: Natural; 

Sort_type: Natural; 

Sort__rank: Natural; 

Csortid: Natural; 

Children_ids: Children_ids_type; 

ParenMds: Parentjdsjype; 

Ground_term: Symbol name; 

End Record; 

Type Sort_table_types is array(E.SortJd_Range) of A_sort_table_type; 

Type Sort_table_def is 
Record 

Num_of_Sort: Natural; 

Sort table: Sortjable types; 

End Record; 

Type Tstables is array(1..20) of Sort_table_def; 

Type Q2csort is 
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Record 

Qsort: Natural; 

Csort: Natural; 

End Record; 

Type Q2csorts is array (1.. 10) of Q2csort; 

Type Sal_type is 
Record 

Sort_acount: Natural; 

Sort_asgn : Q2csorts; 

End Record; 

Type Sal_types is array (1.. 10) of Sal_type; 

Type Q2cop is 
Record 

Qop : Symbol_name; 

Cop : Symbol_name; 

End Record; 

Type Q2cops is array (1.. 10) of Q2cop; 

Type Oaltype is 
Record 

Op_acount: Natural; 

Op asgn: Q2cops; 

End Record; 

Type Stack 1 is 
Record 

Sal; Sal__type; 

Ovl: Ovl type; 

Oal: Oal type; 

Lope: Lopc_type; 
fi: Natural; 

Stable: Sort table def; 

End Record; 

Type Stackl_type is array (l.TO) of Stack 1; 

Type Stack2 is 
Record 

Sal: Sal_type; 

Stable : Sort table def; 

Svl: SvHype; 

Lds: Lds_type; 
di: Natural; 

End Record; 

Type Stack2_type is array (1..5) of Stack2; 

Type Asig is 
Record 

Sal: Saljype; 

Oal: Oal_type; 
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SignatureRank : Float; 

SemanticRank : Float; 

Testcase: Testcases_status_types; 

Testequations: Testequations_types; 

End Record; 

Type Signature_map is array(l..Max_maps) of Asig; 

Type Op is 
Record 
Rs: Natural; 

Oms : Sort_type; 

Symbol : Symbol_name; 

Profile : Natural; 

End Record; 

Type COp_type is array(1..25) of Op; 

Type QOp type is array(T. 10) of Op; 

Type Symbol^type is 
Record 

Name : Symbol_name; 

Symboltype : Natural; 

Length : Natural; 

End Record; 

Type KeywordList_def is array(1..5) of Natural; 

Type ProfileList_def is array (1.. 11) of Natural; 

Type SWC is 
Record 

Ops ; COp type; 

Num_ops : Natural; 

Obj filename: Symbol name; 

KeywordList: KeywordList_def; 

ProfileList: Profilelist def; 

End Record; 

Type Ground_equation is 
Record 

Eqtext: Test_case__str; 

ProfileList: Profilelist_def; 

Status: Natural; 

End Record; 

Type QGround_equations is array (L.5) of Ground_equation; 

Type QC is 
Record 

Ops : QOp type; 

Num_ops: Natural; 

Num_tcases: Natural; 

Geq: QGround equations; 

ProfileList: Profilelist def; 

KeywordList: KeywordList_def; 
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End Record; 

- For Look up table 

Sort_assignmentJable: Constant Matrix:= 
((FJ)XT,Nill),(FJX(FJ),(F,Nill),(FJ),(T,Nill),(F,Nill),(T,Nill)); 

Type CandidateTable Def is 
Record 

Componentid : Natural; 

ProfileKeywordRank : Float; 

End Record; 

Type CandidatesTable is Array (1..14) of CandidateTable_Def; 
Type Profile_errJist is Array (1 ..5) of Natural; 

End Global_def; 


— Module Name: scs.a 

— Description: This is the main driver for the software 

— component search prototype 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

“ Verified as a first prototyped 


With Op^Util^Mods; Use Op^Util^Mods; 

With Global_def; Use Global_def; 

With Query_processingjpkg; Use Query_pix)cessing_pkg; 

With Swb_pkg; Use Swbjikg; 

With Swb defjpkg; Use Swb def_j}kg; 

With Signature_matchj)kg; Use Signature_match_pkg; 

With Semantic_match_pkg; Use Semantic_match_pkg; 

With Init_pkg; Use Init_pkg; 

With FormulateJResult_Output_pkg; Use Formulate_Result_Output_pkg; 
With FloaMo; Use Float io; 

With Integerio; Use Integerio; 

With TexMo; Use Textjo; 

With Integerjo; Use Integerjo; 

Procedure Main is 
Candidates : CandidatesTable; 

Profile err : Profile^errjist := (Others => Nill); 

Q: Qc; C: SWC; 

V: Signature map; 
i: Natural := 1; 
cl : natural := 0; 
sn : natural; 

Num_vmaps: Natural; 

Stable : Sort_table_def; 

U1,L1: Float; 

KeywordRank, ProfileRank : Float; 

SoitArray : Asoit__Array; 
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Begin 

— Get Query input from user 
putfEnter LI,U1: "); 
get(Ll); get(Ul); 

Put("Enter Sn: 
get(sn); 

Get_Query(Q,Stable); 

- Retrieve components from Library using profile from test cases 
FindCandidateComponents(Q,Candidates,Profile_err); 

While True 
Loop 

If Candidates(i).ComponentId /= Nill then 
Get_Query (Q,Stable); 

Initialize_variables(V,Num_vmaps,Stable); 

InitComponentData(Candidates(i).ComponentId,C,Stable,Q,KeywordRank, 

ProfileRank); 

— Signature Match 

put("Working on :");put(String(C,Obj_filename));NewJine; 
cl :=0; 

Signature_Match(Q,C,V,Stable,Num_vmaps,cl,sn,LkUl,KeywordRank, 

ProfileRank); 

put(”Count number of unfilter map"); put(cl);new_line; 

— Semantic_Match 

Semantic_Match(Q,C,V,Stable,Num_vmaps); 

— Formulate Result and output to user 
Calculatetotal_rank(V,Q,C,i,Num_vmaps,Sort Array, 
KeywordRank,ProfileRank); 
i := i + 1; 

Else 

exit; 

End If; 

End Loop; 

Sort_Display _Result(SortArray ,i-1); 

Display _invalid_operations(Q,Profile_eiT); 

End Main; - End of main 


— Module Name: sigmat.a 

— Description: This is the signature matching procedure for the 

— software component search prototype (Algorithms 10) 

— Author: Nguyen Doan 
History: Nov, 6 1995 
Verified as a first prototyped 


With Op_Util_Mods; Use Op Util Mods; 

With Global def; Use Global def; 

With Sort_assignment_pkg; Use Sort_assignment_pkg; 
With text io; Use text io; 

With integerjo; Use integerio; 
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Package Signature_match_pkg is 

Procedure Signaturejnatch (Q: in QC; C: In SWC;V : In Out Signature Map; 
Stable: In Out Sort_table_def; Num_vmaps: In Out Natural; 

CI,Sn : In Out Natural;LI,UI,KwRank,PrfRank: Float); 

End Signature_match_pkg; 

Package body Signature_match_pkg is 

Procedure Signature match (Q: in QC; C: In SWC;V : In Out Signature Map; 
Stable: In Out Sort table def; Num vmaps: In Out Natural; 

Cl,Sn : In Out Natural;Ll,Ul,KwRank,PrfRank: Float)is 
Tsai: Sal_types; 

Tstable: Tstables; 

Sal: Sal_type; 

Oal: Oal type; 

Ovl: Ovl type; 

Lope : Lopc_type; 

Stack: Stack 1 type; 
stk_idx : Natural := 0; 
fi, pfj, fj, fip : Natural; 

Num_maps: Natural; 

Begin 

Initialize_state_variables(Sal,Oal,Ovl,Lopc,fi); 

While True — Loop until all maps are covered 
Loop 

Q := Find_comp_opJdx(C.Num_ops,fi,Lopc,Ovl); 

Iffj=Nill andfi/=Nill then 
If fi = Q.Num ops then — Both Q and fi finished 
If stk idx = 0 then — If stack is empty, it’s done 
- Show_V(V,Num_vmaps,Stable); - Display result; 

Exit; 

Else 

Verify lJpdate_Rank(Sal,Oal,Stable,V,Num_vmaps,Q,CljSn,Ll,UL 

KwRank,PrfRank); 

Pop(Stack,Stk_idx,Sal,Stable,Oal,Ovl,Lopc,fi); 

If Num_vmaps = Max_maps then 
Return; 

End If; 

End if; 

Else — fi is not finish yet 

Reset_all_previous_visit(C. Num_ops,fi,Lopc,OvI); 
fi := fi + 1; - Get next fi 
End If; 

Else - fj not finish 
Lopc(fj) := True; Ovl(Q) := fi; 

Num_maps := 0; 

If C.Ops(Q).Profile = Q,Ops(fi).profile then 
Resetj3revious_visit(C.Num_ops,fi,fj,Lope,Ovl); 
Sort_assignment(Q.Ops(fi).Dms,C.Ops(Q).Dms,Q,Ops{fi).Rs, 

C. Ops(fj ).Rs, Sal, Stable,T sal,T stable ,Num_maps); 
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If Num_maps > 0 then There’s possible sort maps 
Push(Sal,Stable,Oal,Ovl,Lopc,fi,Stk_idx,Stack); 
Update_Oal(Q.Ops(fi).Symbol,C.Ops(fj).symbol,Oal); 
Push_Individual_Sals(Num_maps,Tsal,Tstable,Sal,Stable,Oal, 
Ovl,Lopc,fi, Stk idx, Stack); 
Pop(Stack,Stk_idx,Sal,Stable,Oal,Ovl,Lopc,fi); 

If fi < Q.Num_ops then 
fi:=fi + l; 

Else - Keep fi constant 

Verify _Update_Rank(Sal,Oal,Stable,V,Num_vmaps,Q,C 1 ,Sn,Ll,Ul, 
KwRank,PrfRank); 

Pop(Stack,StkJdx,Sal,Stable,Oal,Ovl,Lopc,fi); 

If Num vmaps = Max maps then 
Return; 

End If; 

End If ; 

End If; 

End If; 

End if; 

End Loop; 

End Signature_Match; 

End Signature_Match_pkg; - End of signature match 


— Module Name: nsa.a 

— Description: This module peforms the sort assignment for the 

— Signature Matching Algorithm. 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

— Verified as a first prototyped 


With GlobaI_def; Use Global_def; 

With So_Util_Mods; Use So_Util_Mods; 

With Sort assignable__pkg; Use Sort assignable_pkg; 

With Text io; Use Text io; 

With Integer_io; Use Integer Jo; 

Package Sort_assignmentj)kg is 

Procedure Sort_assignment(Qsd,Csd: Sort_type;Qsr,Csr: Natural; 
Sal: Sal_type; Sortjable: Sort_table_def; Tsai: out Sal types; 
Tstable: out Tstables; Num_maps: in out Integer); 

End Sort_assignment_pkg; 

Package body Sort_assignment_j>kg is 

Procedure Sort_assignment(Qsd,Csd: Sort_type;Qsr,Csr: Natural; 
Sal: Sa^type; Sortjable: SortJable__def; Tsai: out Saltypes; 
Tstable: out Tstables; Num_maps: in out Integer) is 
Svl: Svl type; 
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Lds : Lds_type; 
di : Natural; 
dj,pdj: Natural; 

Salp: Sal_type := Sal; 

Stable: Sort_table_def:= Sort_table; 

Stk_idx: Natural := 0; 

Stack: Stack2_type; 

Sort_exist: Boolean; 

Begin 

Initialize_state_variables(Svl,Lds,di); 

— First, check range sort 

If Assignable(Qsr,Csr,Stable) = T then 
Sort_exist := False; 

For i in 1 ..Sal.Sort_acount 
Loop 

If Qsr = Sal.Sort_asgn(i).Qsort then 
Sort_exist := True; - Sort assigment existed 
Exit; 

End If; 

End Loop; 

If Sort_exist = False then 
Update_Sort(Qsr,Csr,Salp,Stable); 

End If; 

If Num_sort(Csd) = 0 then — operator is constant 
If Sort_exist = False then 
Num_maps := Num_maps + 1; 

Tstable(Num_maps) := Stable; 

Tsal(Num_maps) := Salp; 

Return; 

End If; 

End If; 

Else 

Return; 

End If; 

— Second, check domain sorts 
While True 

Loop 

dj := Find_comp_so_idx(Num_sort(Csd),di,Svl,Lds); 
pdj := Findj)revious_comp_so_idx(Num_sort(Csd),di,Svl); 
If dj = Nill or di = Nill then 
If stk idx = 0 then - If stack is empty 
Exit; - Done 
Else 

Pop(Stack,Stk_idx,Salp,Svl,Lds,Stable,di); 

End if; 

Else 

If pdj /= Nill then 
Lds(pdj) := False; 

End if; 

Lds(dj) := True; Svl(dj) := di; 

If Assignable(Qsd(di),Csd(dj),Stable) = T then 
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Sort_exist := False; 

For i in 1 ..Sal.Sort_acounl 
Loop 

If Qsd(di) = SalSort_asgn(i),Qsort then 
Sort_exist := True; — Sort assigment existed 
Exit; 

End If; 

End Loop; 

If Sort_exist = False then 
Push(Salp,Svl,Lds,di,Stable,Stkjdx,Stack); 
Update_Sort(Qsd(di),Csd(dj),Salp,Stable); 
End If; 
di := di + 1; 

If di > Nuni_sort(Qsd) then 
Num_maps := Num_maps + 1; 
Tstable(Num_maps) := Stable; 
Tsal(Num_inaps) := Salp; 

End if; 

End if; 

End if; 

End Loop; 

End Sort assignment; 

End Sortassignment j)kg; 


— Module Name: asable.a 

— Description: This module determines whether two given sorts can 

— assigned or not. 

“ Author: Nguyen Doan 

— History: Nov, 6 1995 

— Verified as a first prototyped 


With Global_def;Use GlobaLdef; 

With Text Jo;Use Text_io; 

With IntegerJo;Use Integer Jo; 

Package Sort_Assignable_pkg is 

Function Determine_sort_types(Sorti,Sortj: Natural;Sorttable: 
SortJable_def) Return Natural; 

Function Determine sort jnlation(Sorti,Sortj: Natural; Sorttable: 

Sort Jable def) Return Natural; 

Function Assignable(Sorti,Sortj: Natural;Stable: 

Sort_table_def) Return Natural; 

End Sort_assignable_pkg; 

Package body Sort_assignable_pkg is 

Function Determine_sort_relation(Sorti,Sortj: Natural; Sorttable: 
Sort Jable_def) Return Natural is 
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Begin 


- Column 1, rows 7,8,9 or Column l,rows 2,5 
If Sorttable.Sort_table(Sorti).Sort_type = Unconfined or 
Sorttable.Sort_table(Sortj).Sort_type = Unconfined then 
Return Unrelated; 

~ Columns 1,2 rows 4,6 

Elsif Sorttable.Sort_table(Sorti).Sort_type = Confined then 
If Sorttable.Sort_table(Sorttable.Sort_table(Sorti).Csortid).Main_sort 
SoTttable. Sort_table(Sortj ).Main_sort then 
Return Related; 

Else 

Return Unrelated; 

End If; 

- Column 1,2 row 3 

Elsif Sorttable.Sort_table(Sorti).SortJype = Basic and 
Sorttable.Sort_table(Sortj).Sort_type = Basic then 
If Sorttable.Sort_table(Sorti).Main_sort = 
Sorttable.Sort_table(Sortj).Main_sort then 
Return Related; 

Else 

Return Unrelated; 

End If; 

— Column 1,2 row 1 
Else 

If Sorttable. Sort_table(Sorttable. Sort_table(Sortj ).Csortid).Main_sort 
Sorttable. Sort_table(Sorti).Main_sort then 
Return Related; 

Else 

Return Unrelated; 

End If; 

End If; 

End Determinesortrelation; 

Function Detennine_Sort_types(Sorti,Sortj: Natural;Sorttable; 

Sort_table_def) Return Natural is 
Sort type_i,Sort_typeJ : Natural; 

Begin 

Sort type_i := Sorttable.Sort_table(Sorti).Sort_type; 

Sort typeJ := Sorttable.Sort table(Sortj).Sort_type; 

~ Look for row number 

If Sort type i = Basic and Sort typeJ = Confined then 
Return 1; 

Elsif Sort type i = Basic and Sort typeJ = Unconfined then 
Return 2; 

Elsif Sort_type_i = Basic and Sort_typeJ = Basic then 
Return 3; 

Elsif Sort type i = Confined and Sort typeJ = Basic then 
Return 4; 

Elsif Sort_typeJ = Confined and Sort_typeJ = Unconfined then 
Return 5; 
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Elsif Sort_type_i = Confined and Sorl_typeJ = Confined then 
Return 6; 

Elsif Sort_type_i = Unconfined and Sort_typeJ = Basic then 
Return 7; 

Elsif Sort_type_i = Unconfined and Sort_typeJ = Confined then 
Return 8; 

Else 

Return 9; 

End If; 

End Determine_sort_types; 

Function Assignable(Sorti,Sortj: Natural; Stable: 

Sort_table_def) Return Natural is 
Row, Column: Natural; 

Begin 

If Sorti = Nill or Sortj = Nill then 
Return F; 

Else 

Row := Determine_Sorl_types(Sorti,Sortj,Stable); 

Column := Determine_Sort_Relation(Sorti,Sortj,Stable); 
Retum(Sort_assignment_table(Row,Column)); 

End If; 

End Assignable; 

End Sort_assignable_pkg; 


-- Module Name: Utilop.a 

- Description: This module does the utilities functions for the main 

- Signature Matching algorithm which is Sigmat.a. 

- Author: Nguyen Doan 

- History: Nov, 6 1995 

- Verified as a first prototyped 


With Global_def;Use Global_def; 

With Text_io;Use Text_io; 

With Integer_io;Use Integer io; 

With Float_io;Use Float_io; 

With Semops_match_pkg; Use Semops_match_pkg; 

Package Op_Util_Mods is 

Procedure Push(Salp: In Sal_type; Stable: Sort_table_def; Oalp: In Oal_type; 
Ovlp: In Ovl_type; Lopcp: Lopc_type;fip: In Natural; Stk_idx: 

In Out Natural;Stack: Out Stackl Jype); 

Function Submapof(Oal : Oaljype; V: Signature^map; i: Natural) 

Return Boolean; 

Function Find_comp_op_idx(Num_ops,fi: Natural; Lope: Lopc_type; 

Ovl: Ovl type) return Natural; 

Procedure Reset_all_previous_visit(Num_ops,fi: Natural; 

Lope: out Lope type; Ovl: in Ovl type); 

Procedure Reset_previous_visit(Num ops,fi,fj: Natural; 

Lope: out Lope type; Ovl: in out Ovl type); 

Procedure Pop(Stack: In Stack l_type;StkJdx: In Out Natural; 
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Salp: Out Sal_type; Stable: out Sort_table_def; Oalp: 

Out Oal_type; Ovlp: Out Ovl_type; Lopcp: Out Lopc_type; 
fip: Out Natural); 

Procedure Update_Oal(Qsymbol,Csymbol: In Symbol_name; 

Oal: In Out OaMype); 

Procedure Verify_Update_Rank(Sal: Sal_type;Oal: OaMype;Stable: 
Sort_table_def; V: In Out Signature_map; Num_vmaps: 

In Out Natural;Q : Qc;cl,sn: In Out Natural;Ll,Ul,KwRank, 

PrfRank: Float); 

Procedure Initialize_state_variables(Sal: Out Sal_type; Oal: Out Oal_type; 
Ovl: out Ovl type; 

Lope: Out Lopc_type; fi: Out Natural); 

Function CheckTopValue(Oal: Oal type; Q: Qc) Return Boolean; 
Procedure Push_Individual_Sals(Num_maps: In Natural;Tsal: In Sal_types; 
Tstable: in Tstables; Sal: In Out Sal type; Stable: In out 
Sort_table_def; Oal: In Oal type; Ovl: In Ovl type; 

Lope: Lopc_type; fi: In Natural; Stk_idx : In Out Natural; 

Stack: Out Stack l_type); 

Procedure Show_V(V: Signature map; Num vmaps: Natural;Stable: 
Sort_table_def); 

End Op_Util_Mods; 

Package body Op_Util_Mods is 

Procedure Show_V(V: Signature map; Num vmaps: Natural;Stable: 
Sort_table_def) is 

Begin 

For i in L.Num_vmaps 
Loop 

Put(’'-H--H--Hh-H-4-i-+-H-”); Newjine; 

PutC'Map #”); Put(i); Newjine; 

Put(”++'fH~HHH--HH-++"); NewJine; 

Put(" Sort Assignment: ”);New_line; 

Forj in L.V(i).Sal.Sort_acount 
Loop 

Put(String(Stable.SortJable(V(i).Sal.Sort_asgn(j).Qsort).Sort_symbol)); 

PutC->"); 

Put(String(Stable.Sort_table(V(i).Sal.Sort_asgn(j).Csort).Sort_symbol)); 

NewLine; 

End Loop; 

PutC’ Operator Assi gnment: ” );New_line; 

For j in l ..V(i).OaLOp_acount 
Loop 

Put(String( V(i). Oal. Op_asgn(j). Qop)); 

Put('’->"); 

Put(String(V(i).Oal.Op_asgn(j).Cop)); 

New_Line; 

End Loop; 

Put(" SignatureRank: ”); 
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Put(Float( V(i). SignatureRank),4,1 );New Jine; 
End Loop; 

End Show_V; 


Procedure Push_Individual_Sals(Nuni_maps: In Natural;Tsal: In Sal_types; 
Tstable: in Tstables; Sal: In Out Saljype; Stable: In out 
Sort_table_def; Oal: In Oal type; Ovl: In Ovl_type; 

Lope: Lopc_type; fi: In Natural; Stk Jdx : In Out Natural; 

Stack: Out Stackl_type) is 
Begin 

For n in L. Num_maps 
Loop 

Stable := Tstable(n); 

Sal.Sort_asgn := Tsal(n).Sort_asgn; 

SalSort_acount := Tsal(n).Sort_acount; 
Push(Sal,Stable,Oal,Ovl,Lopc,fi,StkJdx,Stack); 

End Loop; 

End PushIndividualSals; 

Procedure Verify_Update_Rank(Sal: Sal_type;Oal: Oal_type;Stable: 

Sort table^def; V: In Out Signature^map; Num_vmaps: 

In Out NaturaUQ : Qc;cl,Sn: In Out Natural;Ll,Ul,KwRank, 
PrfRank: Float) is 
CofSuccess: Float; 
j : Natural := 1; 

Flag : Boolean := True; 

Ref_sort,Child_ref_sort,Count: Natural; 

Begin 

~ First verify subsort relation; 

For i in Bquery sort..Equery_sort 
Loop 

If Stable.Sort_table(i).Sort_id /= Nill and 
Stable.Sort_table(i).Csortid I- Nill then 
Ref_sort := Stable.Sort_table(i).Csortid; 

While Stable.SortJable(i).ChildrenJds(j) /= Nill 
Loop 

IfStable.Sort_^table(Stable.Sort_table(i).Children_ids(j)).Csortid 

/= Nill then 
Child_ref_sort := 

Stable.SortJable(Stable.SortJable(i).ChildrenJds(j)).Csortid; 

If Stable.Sort_table(Ref_sort).Sort_rank < 

Stable. Sort Jable(Child_ref_sort). Sort^rank or 
Stable. Sort_table(Ref_sort).Main_sort /= 

Stable. Sort Jable(Child_ref_sort).Main_sort then 
Flag := False; -- Sorts are not presevered in ordered. 

Exit; 

End If; 
j:=j + l; 

End If; 

End Loop; 

End If; 
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End Loop; 

If Flag = True then — Sort are presevered in ordered. 

-- Now check for uniqueness 
Count := 0; 

Fori in l..Num_vniaps 
Loop 

If not Submapof(Oal,V,i) then 
Count := Count + 1; 

End If; 

End Loop; 

If Count = Num_vmaps then 
CofSuccess := 

KwRank * PrfRank * Float(Oal.Op_acount) /Float(Q.Num_ops); 
If CheckTopValue(Oal,Q) 
and then CofSuccess > LI and then 
CofSuccess <= U1 then 
cl :=cl + 1; 

If cl > sn * Max_maps then 
If cl mod Max_maps = 0 then 
put(”Waming Max maps reach");new_Iine; 

Num_vmaps := Max_maps; 

Else 

Num_vmaps := cl mod Max_maps; 
V(Num_vmaps).Oal.Op_asgn := Oal.Op_asgn; 
V(Num_vmaps).Oal.Op_acount := Oal.Op acount; 
V(Num_vmaps).Sa!.Sort_asgn := SalSort asgn; 
V(Num_vmaps).SalSort_acount := SaLSort_acount; 
V(Num_vmaps),SignatureRank := 

Float(OaLOpacount) / Float(Q.Num_ops); 

End If; 

End If; 

End If; 

End If; 

End If; 

End Verily_update_Rank; 

Function CheckTopValue(Oal: Oal_type; Q: Qc) Return Boolean is 
Tempsymbol: Test case str; 

Begin 

Fori in L.Oal.Op_acount 
Loop 

For j in L.Q.Num_tcases 
Loop 

Tempsymbol := (others => ' ’); 

For m in 1 ..Test_case_str’Length 
Loop 

If Oal.Op_Asgn(i).Qop(m) = ' ’ then 
Tempsymbol(m) 

Exit; 

End If; 

Tempsymbol(m) := Oal.Op_Asgn(i).Qop(m); 
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End Loop; 

If Top_value(Q.CTeq(j).Eqtext,Tempsymbol) then 
Return True; 

End If; 

End Loop; 

End Loop; 

Return False; 

End CheckTopValue; 

Function Submapof(Oal : Oal_type; V: Signature^map; i: Natural) 

Return Boolean is 
Flag: Boolean; 

Count: Natural := 0; 

Begin 

Form in L.OaLOp_acount 
Loop 

Flag := False; 

Fork in L.V(i).Oal.Op_acount 
Loop 

If V(i).Oal.Op_asgn(k).Qop = OaLOp_asgn(m).Qop and 
V(i).OaLOp_asgn(k).Cop = Oal.Op_asgn(m).Cop then 
Flag := True; 

Count Count + 1; 

Exit; 

End If; 

End Loop; 

End Loop; 

If Count = Oal.Op_acount then 
Return True; 

Else 

Return False; 

End If; 

End Submapof; 

Procedure Initialize_state_variables(Sal: Out Sal_type; Oal; Out Oal_type; 
Ovl: out Ovl_type; 

Lope: Out Lopc_type; fi: Out Natural) is 

Begin 

SaLSort_Acount := 0; -- Note: there's no need for initialize Qsort, Csort. 
Oal.Op Acount := 0; — Same here. 

Forj in L.Ovl'Length 
Loop 

Ovl(j) := Nill; 

Lopc(j) := False; 

End loop; 
fi := 1; 

End Initializestatevariables; 

Function Find__comp_opJdx(Num_ops,fi: Natural; Lope: Lopc_type; 

Ovl: Ovl jype) return Natural is 
Begin 
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For i in 1 ..Num_ops 
Loop 

If Ovl(i) /= fi and Lopc(i) /= True then 
Return i; 

End If; 

End Loop; 
return Nill; 

End Find_comp_op_idx; 

Procedure Reset_allj?revious_visit(Num_ops,fi: Natural; 

Lope: out Lopc_type; Ovl: in Ovl_type) is 

Begin 

Fori in L.Num_ops 
Loop 

If Ovl(i) = fi then 
Lopc(i) := False; 

End If; 

End Loop; 

End Reset_all j3revious_visit; 

Procedure Resetj)revious_visit(Num_ops,fi,fj: Natural; 

Lope: out Lopc_type; Ovl: in out Ovl_type) is 

Begin 

Fori in L.Num_ops 
Loop 

If Ovl(i) = fi and i /= f} then 
Lope(i) :== False; 

End If; 

End Loop; 

End Resetjprevious_visit; 

Procedure Push(Salp: In Sal type; Stable: Sort table def; Oalp: In Oal type; 
Ovlp: In Ovl type; Lopep: Lopc_type;fip: In Natural; Stkjdx: 

In Out Natural;Stack: Out Stackl type) is 

Begin 

Stk idx := Stkjdx + 1; 

Stack(StkJdx).Sal.Sort_asgn := Salp.Sort_asgn; 

Stack(Stk idx).SaLSort_acount := Salp.Sort acount; 
Stack(StkJdx).Oal.Op_asgn := Oalp.Op_asgn; 

Stack(Stk idx).Oal.Op_acount :== Oalp.Op acount; 

Stack(Stk idx).Stable := Stable; 

Stack(StkJdx).Lopc := Lopep; 

Stack(StkJdx).Ovl := Ovlp; 

Stack(StkJdx).fi := fip; 

End Push; 

Procedure Pop(Stack: In Stack l_type; Stkjdx: In Out Natural; 

Salp: Out Sal_type; Stable: out Sort table def; Oalp: 

Out Oal type; Ovlp: Out Ovl type; Lopep: Out Lopcjype; 
fip: Out Natural) is 

Begin 
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Salp.Sort_asgn := Stack(Stk_idx).Sal.Sort_asgn; 

Salp.Sort_acount := Stack(Stkjdx).SaLSort_acount; 

Oalp-Op_asgn := Stack(Stkjdx).Oal.Op_asgn; 

Oalp.Op_acount := Stack(Stk_idx).Oal.Op_acount; 

Ovlp := Stack(Stk_idx).Ovl; 

Stable := Stack(Stk_idx).Stable; 

Lopcp ;= Stack(Stk_idx).Lopc; 
fip := Stack(Stkjdx).fi; 

Stk_idx := Stk_idx - 1; 

End Pop; 

Procedure Update_Oal(Qsymbol,Csymbol:In Symbol_^name; Oal: In Out Oal type) is 
Begin 

Oal.Op acount := Oal.Op acount + 1; 

OaLOp_asgn(Oal.Op_acount).Qop := Qsymbol; 

OalOp__asgn(Oal.Op_acount).Cop := Csymbol; 

End UpdateOal; 

End Op_Util_Mods; 


- Module Name: Utilso.a 

- Description: This module does the sort utilities functions for the 

- main Signature Matching algorithm which is Sigmat.a. 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

— Verified as a first prototyped 


With Global_def;Use Global^def; 

With Text_io;Use Textjo; 

With Integer_io;Use Integerjo; 

Package So_Utii_Mods is 

Procedure Push(Salp: Sal^type; Svl: Svl_type; Lds: Lds_^type; di: Natural; 

Stable: Sort Jable_def;StkJdx: In Out Natural; Stack: 

Out Stack2 type); 

Function Find_comp_so_idx(Num_sos,di: Natural;Svl: Svl_type, Lds. Lds_type) 
return Natural; 

Function Find__previous_comp_soJdx(Num_sos,di: Natural; Svl: Svl_type) 
return Natural; 

Procedure Pop(Stack: In Stack2_type;StkJdx: In Out Natural; 

Salp: Out Sa^type; Svl: Out Svl^type; Lds: Out Lds^^type; 

Stable: Out SortJable__def;di: Out Natural); 

Procedure Update_Sort(Sorti,Sortj: Natural; Sal: In Out Sal_type; 

Sorttable: In Out Sort Jable__def); 

Procedure Initialize__state_variables(Svl: Out Svl type; 

Lds: Out Lds_type;di: Out Natural); 

Function Num_sort(Sort arr: SortJype) return Natural; 


End So_Util_Mods; 

Package body So_Util_Mods is 
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Function Num_sort(Sort_aiT: Sort_type) return Natural is 
Begin 

Fori in l..Sort_type'Length 
Loop 

If Sort_arr(i) = Nill then 
Return (i-1); 

End If; 

End Loop; 

Return Nill; — Return Error if get here. 

End Num_sort; 

Procedure Initialize state variables(Svl: Out Svl type; 

Lds: Out Lds_type;di; Out Natural) is 

Begin 

Forj in L.Lds’Length 
Loop 

Lds(j) := False; 

Svl(j) := Nill; 

End loop; 
di := 1; 

End Initialize_state_variables; 

Function Find_comp_so_idx(Num_sos,di: Natural;Svl: Svl_type; Lds: Lds_type) 
return Natural is 
Begin 

Fori in L.Nuni_sos 
Loop 

If Svl(i) /= di and Lds(i) /= True then 
Return i; 

End If; 

End Loop; 
return Nill; 

End Find_comp_so_idx; 

Function Find_j)revioas_comp_so_idx(Num_sos,di: Natural; Svl: Svl_type) 
return Natural is 
Begin 

Fori in L.Num^sos 
Loop 

If Svl(i) = di then 
Return i; 

End If; 

End Loop; 
return Nill; 

End Find_previous_comp_so_idx; 

Procedure Push(Salp: Sal_type; Svl: Svl_type; Lds: Lds_type; di: Natural; 

Stable: Sort_table_def;Stk_idx: In Out Natural; Stack: 

Out Stack2 type) is 

Begin 

Stkjdx := Stk_idx + 1; 
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Stack(Stkjdx).Sal.Sort_asgn := Salp.Sort_asgn; 
Stack(Stk_idx).Sal.Sort_acount := Sa!p.Sort_acount; 
Stack(Stk_idx).Lds := Lds; 

Stack(Stk_idx).Svl := Svl; 

Stack(StkJdx).di := di; 

Stack(Stk_idx).Stable := Stable; 

End Push; 

Procedure Pop(Stack: In Stack2_type;Stk_idx: In Out Natural; 
Salp: Out Sal_type; Svl: Out Svl_type; Lds: Out Lds_type; 
Stable: Out Sort_table_def;di: Out Natural) is 

Begin 

Salp.Sort_asgn := Stack(Stk_idx).Sal.Sort_asgn; 
Salp.Sort_acount := Stack(Stk_idx).Sal.Sort_acount; 

Svl := Stack(StkJdx).Svl; 

Lds := Stack(Stk_idx),Lds; 
di := Stack(StkJdx).di; 

Stable := Stack(Stk_idx).Stable; 

StkJdx := Stk jdx -1; 

End Pop; 

Procedure Update_Sort(Sorti,Sortj: Natural; Sal: In Out SaMype; 

Sorttable: In Out Sort table def) is 
Sort_exist: Boolean; 

Begin 

Sort_exist := False; 

For i in 1.. Sal. Sort_acount 
Loop 

If Sorti = Sal.Sort_asgn(i).Qsort then 
Sort_exist := True; — Sort assigment existed 
Exit; 

End If; 

End Loop; 

If Sort_exist = False then — New sort assignment 
Sal.Sort acount := Sal.Sort acount + 1; 
Sal.Sort_asgn(Sal.Sort_acount).Qsort := Sorti; 
Sal.Sort_asgn(Sal.Sort_acount).Csort := Sortj; 

End If; 

If Sorttable.Sort_table(Sorti).Csortid = Nill then 
If SorttabIe.SortJabIe(Sorti).Sort_type = Unconfmed then 
Sorttable.SortJable(Sorti)-Sort_type := Confined; 

End If; 

Sorttable.Sort_table(Sorti).Csortid := Sortj; 

End If; 

If Sorttable.Sort_table(Sortj).Csortid = Nill then 
If Sorttable. Sort_table(Sortj).Sort_type == Unconfmed then 
Sorttable.Sort_table(Sortj).Sort_type := Confined; 

End If; 

Sorttable. Sort_table(Sortj).Csortid := Sorti; 

End If; 

End Update_sort; 
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End So_Util_Mods; 


- Module Name: init.a 

- Description: This module initializes the Map table and component 

- variables for preparing for signature matching process. 

- Author: Nguyen Doan 
-- History: Nov, 6 1995 

- Verified as a first prototyped 


With Global def; Use Global def; 

With textjo; Use textjo; 

With integer_io; Use integer_io; 

Package Init_pkg is 

Procedure Initialize_variables(V: Out Signature_map; 

Numjvmaps : Out Natural; Stable: Out Sort table def); 
End Init_pkg; 

Package body Init_pkg is 

Procedure Initialize_variables(V; Out Signature map; 

Numjvmaps : Out Natural; Stable: Out Sort_table_def) is 

Begin 

— Initialize Signature Map variables 
Num_vmaps := 0; 

For i in 1 ..Signaturemap'Length 
Loop 

For j in l..Testequations_types'Length 
Loop 

V(i).Testequations(j).evalue := (Others => ''); 

End Loop; 

End Loop; 

— Initialize Sort table for component 
For i in 10..20 

Loop 

Stable.Sort_table(i).Sort_id := Nill; 

Stable.Sort_table(i).Sort_Symbol := (Others =>' ’); 

Stable.Sort_table(i).Main_sort := Nill; 

Stable.Sort_table(i).Sort rank := Nill; 

Stable.Sort_table(i).Sort_type := Unconfined; 
Stable.Sort_table(i).Csortid := Nill; 

Stable.Sort_table(i).Children ids :== (Others => Nill); 
Stable.Sort_table(i).Parent_ids := (Others => Nill); 

End Loop; 

End Initialize variables; 

End Init_pkg; - End of signature match 
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— Module Name: semata 

- Description: This module does the semantic matching operation. 
-- Author: Nguyen Doan 

— History: Nov, 6 1995 

- Verified as a first prototyped 


With Global_def; Use Global_def; 

With Semops_match j)kg; Use Semops_match_pkg; 

With texMo; Use text_io; 

With integer_io; Use integer Jo; 

Package Semantic_match_j)kg is 

Procedure Semantic^match (Q: in QC; C: In SWC;V : In Out Signature_Map; 

Stable: Sort_table_def;Num_vmaps: In Natural); 

End Semantic_match_pkg; 

Package body Semantic_match_pkg is 

Procedure Semantic_match (Q: in QC; C: In SWC;V : In Out Signature_Map; 
Stable: Sort_table_def;Num_vmaps: In Natural) is 


Begin 

Translate_ground__equations(Q,C,V,Stable,Num__vmaps); 

ExecuteJest_cases(V,Num_vmaps,Q,C.Obj_filename,Stable); 

Semantic_rank(V,Num_vmaps,Q); 

End Semantic_Match; 

End Semantic_Match_pkg; - End of Semantic match 


- Module Name: semat.a 

- Description: This module does the semantic matching operations for 
—semat.a 

- Author: Nguyen Doan 

- History: Nov, 6 1995 

- Verified as a first prototyped 


with TEXT JO, SYSTEM; 
use TEXTJO, SYSTEM; 

With Global_def; Use Global_def; 

With integer Jo; Use integerio; 

With Float Jo; Use Float Jo; 

Package Semops_match_pkg is 

Dot: Constant := 1; 

Groundsort: Constant := 2; 

Op : Constant := 3; 

Undefined : Constant := 4; 

Defined : Constant := 5; 

Procedure System caIl(command: String); 
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Procedure Convert_ground_sort(Tsymbol,Psymbol: Symbol_name;SymbolName: In out 
Symbol_name;V : Signature_niap;Num_arg: Natural;Num_Tnap: Natural; 
Q;QC;Stable: Sort table def); 

Procedure Getasymbol(Q: Qc;Stable: Sort_table_def;V: Signature_map; 
Tcase_str:Test_case_str;Strj:>tr: In Out Natural ;Num_map: Natural; 

Num_arg : In Out Natural; Psymbol: In Out Symbol_name; 

Symbol: In Out Symbol_type;Ext_stuff: In Out Symbol_name; 

Length_Ext: Out Natural); 

Procedure Translate_ground_equations(Q: in QC; C: In SWC;V : In Out 
Signature_Map; Stable: Sort_table_def;Num_vmaps: In Natural); 

Procedure Get_make_statement(V: Signature_map;Mapnum: Natural;Makestm: In Out 
Test_case_str;Filename: Symbol__name; Stable: Sort_table_def; Flag: 

Out Boolean); 

Procedure Execute_test_cases(V: In Out Signature_map;Num_vmaps: Natural;Q: QC; 
Filename : Symbol_name;Stable: Sort_table_def); 

Procedure Semantic_rank(V: In Out Signature_map;Num_vmaps: Natural; 

Q: Qc); 

Function Top_value(Equl,Equ2: Test__case_str) Return Boolean; 

End Semops_match_pkg; 

Package body Semops_match_pkg is 

Function Top_value(Equl,Equ2: Test_case_str) Return Boolean is 
i: Natural := 1; 

Begin 
While True 
Loop 

If i = Test case str'Length then 
Return True; 

Elsif Equl(i) = Equ2(i) and Equl(i) /= '(’ then 
i := i + 1; — Normal path 
Elsif Equl(i) = Equ2(i) and Equl(i) = ’(’ then 
Return True; 

Else 

Return False; 

End If; 

End Loop; 

End Top_Value; 

Procedure Semantic__rank(V: In Out Signature_map;Num_vmaps: Natural; 

Q: Qc) is 

Input_File : Text_IO.File_Type; 

Input_Line : String(L-13); 
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Len : Integer; 
equationf: Natural; 

Success : Natural; 

Begin 

Open(Input_File,In_File,”testrun.dat”); - Note, it can recreate using objfile 

— Initialize Complete flags to be false, success = 0 
For i in l..Num_vmaps 

Loop 

For j in 1..Q.Num_tcases 
Loop 

V(i).Testcase(j).Complete := False; 

End Loop; 

End Loop; 

- Now, Calculate mu 
Reset(Input_File); 

For i in L.Num_vmaps 
Loop 

Forj in L.Q.Num_tcases 
Loop 

If V(i).Testcase(j).Complete = False then 
If V(i).Testcase(j).Top_function = Undefined then 
V(i).Testcase(j).Complete := True; 

V(i).Testcase(j).Mul_value := 0.0; 

Elsif V(i).Testcase(j).Top_function = Defined and 
V(i).Testcase(j).Translate = False then 
V(i).Testcase(j).Complete := True; 

V(i).Testcase(j).Mul_value := 1.0; 

Elsif V(i).Testcase(j).Top_function = Defined and 
V(i).Testcase(j).Translate = True then 
- Calculate equation(f) 

Equationf := 0; 

Form in L.Q.NumJcases 
Loop 

If Top_value(V(i).Testequations(m).evaIue, 
V(i).Testequations(j).evalue) then 
equationf := equationf + 1; 

End if; 

End Loop; 

— Count success(f) 

Success :=0; 

Form in L.Q.Num teases 
Loop 

If Top_value(V(i).Testequations(m).evalue, 
V(i).Testequations(j).evalue) and 
V(i). Testcase(m). Translate = True then 
Input line := (others => ' ’); 

If not End_Of_file(Input_File) then 
Get_line(Input_File,Input_Line,len); 
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If Input_Line(7) = ‘f OR Input_Line(7) = T’ THEN 
Success := Success + 1; 

End If; 

End If; 

End If; 

End Loop; 

V(i).Testcase(j).Mul_vaIue := 

1.0 + Float(Success) / Float(equationf) - 
(Float(equationf) - Float(success)) / Float(equationf); 

For m in 1 ..Q.NumJcases - Null out the rest of testcases 
Loop 

If Top_value(V(i).Testequations(m).evalue, 
V(i).Testequations(j).evalue) then 
V(i).Testcase(m).Complete := True; 

End If; 

End Loop; 

Else Null; 

End If; 

End If; 

End Loop; 

End Loop; 

Close(Input_File); — Done, close inputfile 

- Initialize Complete flags to be True 
For i in L,Num_vmaps 

Loop 

For j in L.Q,Num__tcases 
Loop 

V(i).Testcase(j).Complete := True; 

End Loop; 

End Loop; 

- Now, Calculate SemanticRank 
For i in L.Num_vmaps 

Loop 

V(i).SemanticRank := 0.0; 

For j in L .Q.Num_tcases 
Loop 

If V(i).Testcase(j).Complete = True then 
V(i).SemanticRank := V(i).SemanticRank + V(i).Testcase(j).Mul_value; 
For m in 1 ..Q.Num tcases — Null out the rest of the test cases 
Loop 

If Top_value(V(i).Testequations(m),evalue, 
V(i).Testequations(j).evalue) then 
V(i).Testcase(m).Complete := False; 

End if; 

End Loop; 

End If; 

End Loop; 

End Loop; 


145 




End Semantic rank; 


Procedure CTet_make_statement(V: Signature_map;Mapnum: Natural;Makestm: In Out 
Test_case_str;Filename: Symbol_name; Stable: Sort_table_def; Flag: 

Out Boolean) is 
i,m,k : Natural; 

Begin 

Flag := True; 

For j in l..V(Mapnum).Sal.Sort_acount 
Loop 

If StabIe.SortJable(V(Mapnum).SalSort_asgn(j).Csort).Sort_symbol(l ..3) = 

”Elt" then 

If Stable.Sort_table(V(Mapnum).SaLSort_asgn(j).Qsort).Sort_symbol{l ..3) 

= "NAT" or 

Stable.SortJable(V(Mapnum).Sal.Sort_asgn(j)Qsort).Sort_symbol(1..3) 

= "INT" or 

Stable.Sort_table(V(Mapnum).Sal.Sort_asgn(j).Qsort).Sort__symbol(L.3) 

= "RAT" then 
Flag := True; 

Makestm(1..16) := "make testobj is"; 
i:=l; 

While True 
Loop 

If Filename(i) = then 
exit; 

Else 

Makestm(i-i-17) := Filename(i); 
i:=i+l; 

End If; 

End Loop; 
i:=i + 17; 

Makestm(i..i) :="["; 
m := 1; 

While True 
Loop 

IfStable.Sort_table(V(Mapnuin).Sal.Sort_asgn(j).Qsort).Sort_symbol(m) 

=' ’ then 
Exit; 

Else 

Makestm(i+m) := 

Stable. Sort Jable(V(Mapnum). Sal. Sort_asgn(j ).Qsort). Sort_symbol(m); 
m := m + 1; 

End If; 

End Loop; 
k := i +m; 

Makestm(k..k+5) :="] endm"; 
exit; - We assume there is only 1 sort assigned to Elt 
Else 

Flag := False; 

End If; 

End If; 
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End Loop; 

End Get_make_statement; 

Procedure System_call(Command : String) is 

procedure system s (command : ADDRESS); 

pragma INTERFACE(C, SYSTEMIC); 

pragma INTERFACE_NAME(SYSTEM_C, "_system"); 

TEMP : constant STRING := command&ASCILNUL; 

ERROR : INTEGER; 

Begin 

SYSTEM_C(TEMP’ADDRESS); 

End System_call; 

Procedure Execute_test_cases(V: In Out Signature_map;Num_vmaps: Natural;Q: QC; 
Filename : Symbol_name;Stable: Sortjable def) is 

the_file: TextJo.file_type; 

str : String(L.70) := (Others => ' ’); 

m : Natural; 

makeflag,Display flag : Boolean; 

Makestm : Test_case_str; 

Flag : Boolean; 

Begin 

Create(the_file,out_file," testca se. dat"); 

— First, create testcase.dat. 

For i in 1 ..Num_vmaps 
Loop 

makeflag := False; 

Makestm := (others => ’'); 

Display flag := True; 

Forj in L.Q.Num tcases 
Loop 

If V(i).Testcase(j).Translate = True then 
If makeflag = False then 

Get_make_statement(V,i,Makestm,Filename,Stable,Flag); 

If Flag = False then 
Fork in L.Q.Num_tcases 
Loop 

V(i).Testcase(k).Translate := False; 

End Loop; 

Exit; 

End If; 

newjine(the_file); 

Put(the_file,string(Makestm)); 
makeflag := True; 

End If; 
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If Display_flag = True then 
Display_flag := False; 
newjine(the_file); 

Put(thejile;’*** "); 

Put(thc_file;*+i t i t i4-f++-f++"); Newjine(the_file); 
Put(thejile;’*** "); 

Put(the_file;’Map #"); Put(the_file,i); Newjine(the_file); 
Put(the_file;’*** ”); 

Put(the_file, ” I i M H t t + 4- M -+" ); NewJine(lhe_file) ; 
Put(the_file;’*** "); 

Put(the_file,"Sort Assignment:”);NewJine(the_file); 

Forjl in l..V(i).Sal.Sort_acount 
Loop 

Put(thejile;’*** ”); 

For k in 1.. Symbol_name'Length 
Loop 

Put(the_file, 

Stable. Sort Jable(V(i). Sal. Sort_asgn(j 1). Qsort). Sort_sy mbol(k)); 
End Loop; 

Put(the_file, 

For kin L.Symbol_name’Length 
Loop 

Put(the_file, 

Stable. Sort_table(V(i). Sal. Sort_asgn(j 1). Csort). Sort_syinbol(k)); 
End Loop; 

New_lme(the_file); 

End Loop; 

Put(the_file,"*** "); 

Put(the_file,"Operator Assignment);New_line(the_file); 

Forjl in L.V(i).Oal.Op_acount 
Loop 

Put(the__file;’*** "); 

For kin l..Symbol_name'Length 
Loop 

Put(the_file,V(i).Oal.Op_asgn(jl).Qop(k)); 

End Loop; 

Put(the_file,"->"); 

For kin l..Symbol_name’Length 
Loop 

Put(the_file,V(i).Oal.Op_asgn(jl).Cop(k)); 

End Loop; 

Newjine(the_file); 

End Loop; 

Put(the_file;'*** "); 

Put(the_file," SignatureRank"); 

Put(the_file,Float( V(i).SignatureRank),4,1 );New_line(the_file); 
End If; 

New_line(the_file); 
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Put(the_file;'*** Cird Eq:”); 

Put(the_file,String(Q.Geq(j).Eqtext)); 

Newjine(the_file); 

Put(the_file,"*** Testcase #"); Put(the_filej); 

New_line(the_file); 

Put(the_file,"reduce"); 

Put(the_file,string(V(i).Testequations(j).evalue)); 

New_line(the_file); 

End If; 

End Loop; 

End Loop; 
close(the_file); 

- second, cp filname testfile.obj 
str(L.4) := "cp "; 

m := 1; 

While true 
Loop 

If Filename(m) = ” or m = SymboI_naine'Length then 
exit; 

Else 

str(m+4) := Filename(m); 
m 1; 

End If; 

End Loop; 

str(16..27) := "tempfile.obj"; 
system_call(str); 

“ Sed to remove control char 
system_call("cat testcase.dat»tempfile.obj"); 
system_call("cat tempfile.obj | sed -e " > testfile.obj"); 

— put("I run obj now!"); newjine; 
sy stem_call(" runobj"); 

“ Save a copy for the wrapper usage later 
str := (Others => ''); 
str(L.15) := "mv testfile.obj"; 
str(16..17) :=" "; 

Fori in l..m 
Loop 

str(18+i) := Filename(i); 

End Loop; 

Str(184in..20+m):=".tc"; 

system_call(str); 

End Executetestcases; 

Procedure Convert_ground_sort(Tsymbol,Psymbol: Symbol_name;SymboIName: In out 
Symbol_name;V : Signature_map;Num_arg: Natural;Num_map: Natural; 
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Q:QC;Stable: Sort_table_def) is 
Csort_type,Qsort_type : Natural := Nill; 

Sortjd,Opjndex,index : Natural; 

Begin 

If Psymbol(l) /= ' ’ then - There exist previous symbol 

— Get Op index 

For i in T.Q.Num_ops 
Loop 

If Q.Ops(i). Symbol = Psymbol then 
Op index := i; 

Exit; 

End If; 

End Loop; 

— Find sort type for query and component 
Sort_id := Q.Ops(Op_index).dms(Num_arg); 

For j in L.V(Num_map).Sal.Sort_acount 
Loop 

If V(Num_map).SaLSort_asgn(j).Qsort = Sortjd then 
QSort type ;= Stable.Sort_table(SortJd).SortJd; 

Csort_type := 

Stable. Sort_table( V(Num_map). Sal. Sort_asgn(j). Csort). Sortjd; 
Exit; 

End If; 

End Loop; 

Else — Constant stand by itself 
If Tsymbol(l) = 't' or Tsymbol(l) = T or 
Tsymbol(l) = T’ or Tsymbol(l) = ’F’ then 
Qsort Type := Bool type; 

Else 

Qsort_type:= Nat_type; 

For i in l..Symbol_name'Length 
Loop 

If Tsymbol(i) = then 
Qsort type := Int type; 
exit; 

Elsif Tsymbol(i) = then 
Qsorttype.- Rattype; 
exit; 

Else 

Null; 

End If; 

End Loop; 

End If; 

— Compute corresponse mapped sort for component sort 
Forj in l..V(Num_map).Sal.Sort_acount 

Loop 

If Stable.SortJable(V(Num_map).Sal.Sort_asgn(j).Qsort).Sortjd 
Qsort type then 
Csort_type := 

Stable. Sort Jable(V(Num_map). Sal. Sort_asgn(j). Csort). Sort Jd; 
Exit; 
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End If; 

End loop; 

End If; 

- Determine SymbolName 
If Qsorttype = Booltype then 
If Csort Type > 10 and Csort Type /= Elt type then 
SymbolName := Stable. Sort_table(Csort_type).Ground_term; 

Else 

SymbolName := Tsymbol; 

End If; 

Elsif Qsort_type = Nat_type then 
If Csort_Type > 10 and Csort_Type /= Elt_type then 
SymbolName := Stable. Sort_table(Csort_type).Ground_term; 

Else -- Csort type = Elt,Int,Float 
SymbolName := Tsymbol; 

End If; 

Elsif Qsort_type = Int_type then 
If Csort_Type >10 and Csort_Type /= Elt_type then 
SymbolNameStable. Sort_table(Csort_type).Ground_term; 

Elsif Csort type = Nat type and Tsymbol(l) = then 
SymbolName(l..Symbol__name’Length) := 
Tsymbol(2..Symbol_name’Length) &' ’; 
else - Csort_type = Elt,Int,Float 
SymbolName := Tsymbol; 

End If; 

Else 

if Csort_Type > 10 and Csort_Type /= Elt_type then 
SymbolName := Stable. Sort_table(Csort_type).Ground_term; 

Elsif Csort type = Int type or Csort type = Nat type then - Truncate it 
Fori in l .Symbol name'Length 
Loop 

If Tsymbol(i) /=then 
SymbolName(i) := Tsymbol(i); 

Else 

index := i; 

For m in i+l..Symbol_name'Length -- Found here 
Loop 

If Tsymbol(m) not in 'O’..’9' then 
SymbolName(Index) := Tsymbol(m); 

Index := Index + 1; 

End If; 

End Loop; 

Exit; 

End If; 

End Loop; 

If SymbolName(l) = and Csortjype = Nat_type then - Remove sign 
SymbolName(l ..Symbol_name'Length) := 
SymbolName(2..Symbol_name'Length)&' 

End If; 

Else - Csort_type = Float,Elt 
SymbolName := Tsymbol; 
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End If; 

End If; 

End Convert_groimd_sort; 

Procedure CietasymboI(Q: Qc;Stable: SortJable_def;V: Signature_map; 
Tcase_str:Test_case_str;Str_ptr: In Out Natural;Num_niap: Natural; 
Num_arg : In Out Natural; Psymbol: In Out Symbol^name; 

Symbol: In Out Symbol^type^Ext^stuff: In Out Symbol^name; 
Length_Ext: Out Natural) is 
Tsymbol : Symbol_name := (Others =>''); 

Temp_ptr: Natural := Strjtr; 

Ex_ptr: Natural; 

Psymflag : Boolean; 

Begin 

-«If first char is char 

If Tcase_str(Strj)tr) m ’A’./Z’ or Tcase_str(Strj)tr) in 'a'..'z’then 

While True 

Loop 

If Tcase_str(Temp jtr) = ’)’ or Tcase_str(Temp_ptr) = or 
Tcase_str(Temp j)tr) = ” or Tcase_str(Tempjptr) = or 
Tcase_str(Temp_ptr) = then 
Exj5tr:= 0; 

Psymflag := False; 

While True - Also get extra stuff & move ptr to 
Loop 

If Tcase_str(Temp_ptr+Ex_ptr) in 'A'..'Z' 
or Tcase_str(Temp_ptr+Ex_ptr) in ’a'..’z' 
or Tcase_str(Temp_ptr+Exj>tr) in’0’./9’ 
or Tcase_str(Temp_ptr+Ex_ptr) = then 
Exit; 

Else 

If Tcase_str(Temp_ptr+Ex_ptr) = '' then 
Psymflag := True; 

End If; 

Ex_ptr := Exjptr + 1; 

End If; 

End Loop; 

Fori in l..Temp_ptr-Str_ptr 
Loop 

Tsymbol(i) := Tcase_str(Strj3tr+'i-l); 

End Loop; 

For i in L.Ex_ptr 
Loop 

Ext_stuff(i) := Tcase__str(Tempj)tr+i.l); 

End Loop; 

exit; - One symbol found 
Else 

Temp_ptr := Tempjptr + 1; - Get pass 1 of char above to new char 
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End If; 

End Loop; 

~ If first char is numeric 

Elsif Tcase_str(Str_ptr) in 'O'..'9' then 

While True 

Loop 

If Tcase_str(Temp_ptr) = ’)' or Tcase_str(Temp_ptr) = '(' or 
Tcase_str(Temp_ptr) ='' or Tcase_str(Tempj3tr) = or 
Tcase_str(Temp_ptr) =then 
Exjptr := 0; 

Psymflag := False; 

While True — Also get extra stuff & move ptr to 
Loop 

If Tcase_str(Temp_ptr+Exjptr) in 'A'..’Z' 
or Tcase_str(Tempj)tr+-Exj3tr) in 'a'..'z' 
or Tcase_str(Temp_ptr+ExjDtr) in '0'..'9' 
or Tcase_str(Tempj3tr+-Ex_ptr) = then 
Exit; 

Else 

If Tcase_str(Temp_ptr+Ex_ptr) = '' then 
Psymflag := True; 

End If; 

Exj)tr := Exj)tr + 1; 

End If; 

End Loop; 

For i in 1 ..Temp_ptr-Strj)tr 
Loop 

Tsymbol(i) Tcase_str(Str_ptri-i-l); 

End Loop; 

Fori in l..Ex_ptr 
Loop 

Ext_stuff(i) := Tcase_str(Temp_ptr+i-l); 

End Loop; 

exit; — One symbol found 
Else 

Temp_ptr := Temp_ptr+1; — Get pass 1 of char above to new char 
End If; 

End Loop; 

Else — Must be a dot since space is skip from above 
Symbol. Symbol type := Dot; 

End If; 

-- Check for valid symbol 
If Symbol. Symboltype /= Dot then 
If Tcase_str(Strjptr) in '0’..'9' or — ground term 
Tcase_str(Str_ptr) = or 
Tcase_str(Str_ptr) =or 
Tcase_str(Str_ptr) = 't' or 
Tcase_str(Strj3tr..Strjptr+3) = "true” or 
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Tcase_str(Str_ptr..Str_ptr-i-3) = ’True” or 
Tcase_str(Str_ptr..Str_ptr+4) = ’’False” or 
Tcase_str(Str_ptr..Str_ptr+4) = ’’false” then 
If Psymflag = True then 

Psymbol := (Others => ’'); - Set flag for constant evaluation 
End if; 

Symbol.Symboltype := Groundsort; 

Convert_ground_sort(Tsymbol,Psymbol,Symbol.Naine,V,Nuin_arg,Nuni_niap, 

Q,Stable); 

If Psymbol(l) /= ’ ’ then 
Num_arg := Num_arg + 1; 

End If; 

Length ext := Ex_ptr; 

Strj)tr := Temp_j)tr; 

Fori in l..Symbol_name’Length 
Loop 

If Symbol.Name(i) = ’' then 
Symbol.Length := iT; 

Exit; 

End If; 

End Loop; 

Else 

Symbol. Symboltype := Nill; 

Forj in L.V(Num_map).Oal.Op_acount 
Loop 

If V(Num_map).Oal.Op_asgn(j).Qop(L.(Temp_ptr-Str_ptr)) = 
Tsymbol(L.(Temp_ptr-Str_ptr)) then 
If Psymflag = False then 

Psymbol := V(Num_map).Oal.Op_asgn(j).Qop; 

Else 

Psymbol := (Others => ''); - Set flag for constant evaluation 
End if; 

Num_arg := 1; 

Symbol.Symboltype ;= Op; 

SymboI.Name := V(Num_map).Oal.Op_asgn(j).Cop; - Tsymbol 

Fori in L.Symbol name'Length 

Loop 

If Symbol.Name(i) = ’' then 
Symbol.Length := i-1; 

Exit; 

End If; 

End Loop; 

Length_ext := Ex_ptr; 

StrjJtr := Tempj)tr; 

Exit; 

End If; 

End Loop; 

If Symbol.Symboltype /= Op then 
Symbol.Symboltype := Undefined; 

End If; 
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End If; 

End If; 

End Getasymbol; 

Procedure Translate_ground_equations(Q: in QC; C: In SWC;V : In Out 
Signature_Map; Stable: Sort_tabIe_def;Num_\Tnaps: In Natural) is 
Save_ptr,Str_ptr, Num_arg : Natural; 

Symbol: Symbol type; 

Psymbol: Symbol^name := (Others => ’'); 

Tflag : Boolean; 

Ext_stuff: Symbol_name := (Others => ''); 

Length_Ext: Natural; 
i: Natural; 

Begin 

ForNum_map in l..Num_vmaps 
Loop 

For tnum in L.Q.Num tcases 
Loop 

Num_arg := 1; 

Psymbol := (Others => ’ ’); 

Str_ptr := 1; 

Savejptr := Strj)tr; 

Symbol.Symboltype := Nill; 

Tflag := False; 

i:-0; 

While True 
Loop 

Symbol.Name := (Others => ' ’); 

Getasymbol(Q,Stable,V,Q.Geq(tnum).Eqtext,Str_ptr,Num_map,Num_arg, 
Psymbol,Symbol,Ext_stuff,Length_Ext); 
i :=i+ 1; 

If Symbol.SymbolType = Dot then - Done 
V(Num_map).testequations(tnum).evalue(Savej?tr+2) := 

Tflag := True; 

Exit; 

Elsif Symbol Symboltype = Undefined then 
Ifi = 1 then 

V(Num_map).Testcase(tnum).Top_function := Undefined; 

End If; 

Tflag := False; 

Exit; 

Else 

If i = 1 then 

V(Num_map).Testcase(tnum).Top_function := Etefined; 

End If; 

Tflag := True; 

Forj in 1. Symbol Length 
Loop 

V(Num_map).testequations(tnum).evalue(Save_ptr-f'j) := 
SymbolName(j); 

End Loop; 
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Forj in l..Length_Ext 
Loop 

V(Nuni_map).testequations(tnuni).evalue(Save_ptr+ 
(Synibol.Length)+j) := Ext_stuff(j); 

End Loop; 

Str_ptr := Str_ptr + Length_ext; 
save_j)tr := Save__ptr+(Symbol.Length)+Length_ext; 
End If; 

End Loop; 

If Tflag = Trae then 

V(Nunii_map).Testcase(tnum).Translate := True; 

Else 

V(Num_map).Testcase(tniiin).Translate := False; 

End If , 

End Loop; 

End Loop; 

End Translate_ground_equations; 

End Semops Matchjpkg; - End of Semops match 


— Module Name: swb def.a 

- Description: This module defines definition for variables for 
—software library. 

“ Author: Nguyen Doan 

— History: Nov, 6 1995 

- Verified as a first prototyped 


Package Swb def_pkg is 

Include : Constant := 1; 
Max_node_range : Constant := 30; 
RootNode : Constant := 0; 

- Keyword id 

Kw Booch : Constant := 1; 
Kw_DataStructure : Constant := 2; 
Kw Stack : Constant := 3; 

Kw Binary tree : Constant := 4; 
Kw Queue : Constant := 5; 

Kw Set : Constant := 6; 

Kw Array : Constant := 7; 
Kw_Bag : Constant := 8; 
Kw_String : Constant := 9; 
Kw_List : Constant := 10; 

Kw Ring : Constant := 11; 
Kw_Deque : Constant := 12; 

- Obj module id 

Stack l obj : Constant := 1; 
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Stack2_obj : Constant := 2; 

Bintl_obj : Constant := 3; 

Bint2_obj : Constant := 4; 

Queue obj : Constant := 5; 

Set_obj : Constant := 6; 

Array_obj : Constant := 7; 

Bag obj : Constant := 8; 

Listl_obj : Constant := 9; 

List2_obj : Constant := 10; 

Ring_obj : Constant := 11; 

Deque_obj : Constant := 12; 

Type Children_id_list is arTay(L. 11) of Natural; 

Type Component id list is array(1.. 11) of Natural; 

Type Profiie_id_list is array(L. 11) of Natural; 

Type Hassenodetype is 
Record 

Visit: Boolean; 

Pipro: Boolean; 

Children list; Children_id_list; 

Componentjist: Component_id_list; 

Piofile List: Profilejdjist; 

End Record; 

Type Hasse_diagrain_type is array(O..Max_node_range) of Hassejaode_type; 
End Swb_def j)kg; 


Module Name: swb.a 

“ Description: This module initialize components data for the 

— software library 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

“ Verified as a first prototyped 


With Global_def; Use GlobaLdef; 

With Swb_defj)kg; Use Swb_def_pkg; 

With textio; Use textio; 

With integerjo; Use integerjo; 

Package Swb_pkg is 

Function DetermineProfileIntersection(GeqProfile:Profilelist_jdef; Pprofile: 
Profile id list) Return Boolean; 

Procedure FindCandidateComponents(Q: In Out Qc; Candidates: In Out 
CandidatesTable; Profile err: Out Profile eir list); 

Procedure IntializeSwb(H : In Out Hasse diagram type); 

Procedure UpdateCandidatesTable(Candidates: Out CandidatesTable; 

H : In Out Hasse_diagram_type;node: Integer;Eoa: In Out 
Natural); 

Function LookupBlockIndex(Pindex: Natural) return Integer; 
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Procedure ReformDfsfw(H: In Out Hasse_diagramJype;Q: Qc; node: Integer; 

Candidates: Out CandidatesTable; Eoa: In Out Natural); 

Procedure InitComponentData(ComponentId: Natural;C: In Out SWC;Stable: 

In Out Sort_table_def;Q : Qc; KwRank, PrfRank : 

Out Float); 

Function ProfileRank(Q: Qc; C : SWC) return Float; 

Function KeywordRank(Q: Qc; C : SWC) return Float; 

End Swbjkg; 

Package body Swb j>kg is 

Function KeywordRank(Q: Qc; C :SWC) return Float is 
Qkeywcardjntersect: Natural := 0; 

Begin 

For i in l. KeywordList defLength 
Loop 

If Q.KeywordList(i) = Nill then 
Exit; 

Else 

Qkeywcard := Qkeywcard + 1; 

Forj in L.KeywordListjdefLength 
Loop 

If Q.KeywordList(i) = C.KeywordList(j) then 
IntersectIntersect + 1; 

End If; 

End Loop; 

End If; 

End Loop; 

If Intersect = 0 then 

PutC'Waming: Incorrect Keyword ranking");New_Line; 

Else 

Retum(Float(Intersect)/Float(Qkeywcard)); 

End If; 

End Key wordRank; 

Function ProfileRank(Q: Qc; C :SWC) return Float is 
Qprofcard,lntersect: Natural := 0; 

Begin 

Fori in L.Profilelist_defLength 
Loop 

If Q.ProfileList(i) = Nill then 
Exit; 

Else 

Qprofcard := Qprofcard + 1; 

Forj in L,Profilelist_defLength 
Loop 

If Q.ProfileList(i) = C.ProfileList(j) then 
Intersect := Intersect + 1; 

End If ; 

End Loop; 

End If; 
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End IvOop; 

If Intersect = 0 then 

Put(" Wamging: Incorrect Profile ranking");New_Line; 

Else 

Retum(Float(Intersect)/Float(Qprofcard))' 

End If; 

End ProfileRank; 

Procedure InitComponenlData(ComponentId: Natural.C. In Out SWC;StabIe: 

In Out SortJable_def;Q ; Qc; KwRank, PrfRank ; 

Out Float) is 

Begin 

Case Componentid is 


- ring.obj 


When ringobj => 

- put("Working on ring_obj"); Newjine; 
“ op empty: -> ring 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "empty "; 

C.Ops(l).m:= 11; 

C.Ops(l).dms(l):= Nill; 

- op copy: Ring Ring -> Ring 

C.Ops(2).Profile :=3301; 
C.Ops(2).Symbol := "copy "; 

C.Ops(2).r5 := 11; 

C.Ops(2).dms(l) := 11; 

C.Ops(2).dms(2) := 11; 

C.Ops(2).dms(3) := Nill; 

- op copy: ERing ERing -> ERing 

C.Ops(3).Profile :=3301; 
C.Ops(3).Symbol := "copy "; 

C.Ops(3).rs := 16; 

C.Ops(3).dms(l) := 16; 

C.Ops(3).dms(2) := 16; 

C.Ops(3).dms(3) := Nill; 

- op clear: ERing -> ERing 
C.Ops(4).Profile :=2201; 

C.Ops(4).Symbol := "clear "; 

C.Ops(4).rs := 16; 

C.Ops(4).dms(l) := 16; 

C.Ops(4).dms(2) := Nill; 

- op insert: Elt Ring -> Ring 
C.Ops(5).Profile := 3211; 
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C.Ops(5).Symbol := "insert 
C.Ops(5).rs := 11; 

C.C)ps(5).dms(l) := 12; 
C.Ops(5).dms(2) ;= 11; 
C.Ops(5).dms(3) := Nill; 

— op insert: Elt ERing -> ERing 
C.Ops(6).Profile := 3211; 

C.Ops(6).Symbol ;= "insert 
C.Ops(6).rs := 16; 

C.Ops(6).dms(l) := 12; 
C.C)ps(6).clms(2) := 16; 
C.Ops(6).dms(3) ;= Nill; 

— op pop: Ring -> Ring 
C.Ops(7).Profile := 2201; 

C.Ops(7).Symbol := "pop 
C.Ops(7).rs := 11; 

C.Ops(7).dms(l) := 11; 
C.Ops(7).dms(2) := Nill; 

— op pop: ERing -> ERing 
C.Ops(8).Profile := 2201; 

C.Ops(8).Symbol := "pop 
C.Ops(8).rs := 16; 

C.Ops(8).clms(l) := 16; 
C.Ops(8).dms(2) := Nill; 

-- op rotate: Direction Ring -> Ring 
C.Ops(9).Profile :=3211; 

C.Ops(9).Symbol := "rotate "; 

C.Ops(9).rs := 11; 

C.Ops(9).dms(l) := 15; 
C.Ops(9).dms(2) := 11; 
C.Ops(9).dms(3) := Nill; 

— op rotate: Direction ERing -> ERing 
C.Ops(10).Profile := 3211; 
C.Ops(10).Symbol := "rotate 
C.C)ps(10).rs := 16; 

C.Ops(10).dms(l) := 15; 
C.Ops(10).dms(2) := 16; 
C.Ops(10).dms(3) := Nill; 


— op mark: ERing -> ERing 
C.Ops(ll).Profile := 2201; 
C.Ops(ll).Symbol := "mark 
C.Ops(l l).rs := 16; 
C.Ops(ll).dms(l) := 16; 
C.Ops(ll).dms(2) := Nill; 




- op rotatetomark: ERing -> ERing 
C.Ops(12).Profile := 2201; 

C.C)ps( 12).Symbol := "rotatetomark 
C.Ops(12).rs := 16; 
C.Ops(12).dms(l):= 16; 
C.Ops(12).dms(2) := Nill; 

“ op isequal: ERing Bring -> Bool 
C.Ops(13).Profile :=3210; 
C.Ops(13).Symbol := "isequal 
C.Ops(13).rs := 13; 
C.C)ps(13).dms(l) := 16; 
C.Ops(13).dms(2) := 16; 
C.Ops(13).dms(3) ;= Nill; 

“ op extentof: Ring -> Nat 
C.Ops(14).Profile := 220; 
C.C)ps(14).Symbol := "extentof 
C.Ops(14).rs := 14; 
C.Oi3s(14).dms(l) := 11; 
C.Ops(14).dms(2) := Nill; 

- op extentof: ERing -> Nat 
C.Ops(15).Profile :=220; 
C.Ops(15).Symbol := "extentof 
C.Ops(15).rs := 14; 
C.Ops(15).dms(l) := 16; 
C.Ops(15).dms(2) := Nill; 

- op isempty . ERing -> Bool 
C.Ops(16).Profile := 220; 

C.Ops( 16).Symbol := "isempty 
C.Ops(16).rs ;= 13; 
C.C)ps(16).dms(l) := 16; 
C,Ops(16).dms(2) := Nill; 

“ op atmatk; ERing -> Bool 
C.Ops(17).Profile := 220; 
C.Ops(17).Symbol := "atmark 
C.Ops(17).rs := 13; 
C.Ops(17).dms(l):= 16; 
C.Ops(17).dms(2):= Nill; 

- op topof: Ring -> Bool 
C.C)ps(18).Profile := 220; 
C.Ops(18).Symbol := "topof 
C.Ops(18).rs ;= 12; 
C.C)ps(18).dms(l) := 11; 
C.Ops(18).dms(2) := Nill; 

- op topof; ERing -> Bool 
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C.0ps(19).Profile ;= 220; 

C.Ops( 19).Symbol := "topof 
C.Ops(19).rs ;= 12; 

C.Ops(19).dms(l):= 16; 

C.Ops(19).dms(2) := Nill; 

— op underflow: -> ring 
C.Ops(20),Profile := 110; 

C.Ops(20).Symbol := "underflow "; 

C.Ops(20).rs := 11; 

C.Ops(20).dms(l) := Nill; 

— op rotaterror: -> ring 
C.Ops(21).Profile := 110; 

C.Ops(21).Symbol := "rotaterror "; 

C.Ops(21).rs := 11; 

C.Ops(21).dms(l):= Nill; 

-- op underflow: -> elt 
C.Ops(22).Profile := 110; 

C.Ops(22).Symbol := "underflow "; 

C.Ops(22).rs := 12; 

C.Ops(22).dms(l):= Nill; 

-- op Forward: -> Direction 
C.Ops(23).Profile := 110; 

C.Ops(23).Symbol := "Forward "; 

C.Ops(23).rs := 15; 

C.Ops(23).dms(l) := Nill; 

-- op Backward: -> Direction 
C.Ops(24).Profile := 110; 

C.Ops(24).Symbol := "Backward "; 

C.Ops(24).rs := 15; 

C.Ops(24).dms(l) := Nill; 

C.Num_ops := 24; 

C.Obj_filename := "ring.obj "; 

C.ProfileList := (110,2201,220,321 l,3301,3210,0thers => Nill); 
C.K^wordList := (Kw_Booch,Kw_DataStructure,Kw_Ring,Others => Nill); 
Stable.Sort_table(ll).Sort_Symbol ;= "Ring 
Stable.Sort_table(ll).Ground_term := "empty 

Stable.Num_of_sort := Stable.Num_of_sort + 1; 
Stable.Sort_table(15).Sort_id := 15; 

Stable.Sort_table(15).Sort_Symbol := "Direction "; 

Stable. Sort_table(l 5). Groundjerm := "forward "; 

Stable.Sort_table(l5).Main_sort := 15; 

Stable. Sort_table(l 5). Sort rank := 1; 

Stable. Sort_table(l 5). Sort_type := Unconfmed; 

Stable. Sort_table(l 5). Csortid := Nill; 
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Stable.Num_of_sort := Stable.Num_of_sort + 1; 
Stable.Sort_table( 16).SortJd := 16; 

Stable.Sort_table(l6). Sort_Symbol := "ERing 
Stable.Sort_table(l6).Ground^term := "empty 
Stable. Sort_table(l6).Main_sort := 11; 

Stable. Sort_table(l 6). Sort_rank := 2; 

Stable. Sort_table(l6). Sort_type := Unconfined; 
Stable.Sort_table(l6).Csortid := Nill; 


- Bint2_obj Binary Tree version two 


When Bint2_obj => 

— putC'Working on bint2_obj"); Newjine; 

— op null: -> Tree 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "null "; 

C.Ops(l).rs := 11; 

C.Ops(l).dms(l):= Nill; 

“ op isnull: Tree -> Bool 
C.Ops(2).Profile := 220; 

C.Ops(2).Symbol := "isnull 
C-Ops(2).rs := 13; 

C.Ops(2).dms(l) := 11; 

C.Ops(2).dms(2) := Nill; 

— op clear. T; Tree -> Tree 
C.Ops(3).Profile :=2201; 

C.Ops(3).Symbol := "clear.T "; 

C.Ops(3).rs := 11; 

C.Ops(3).dms(l):= 11; 

C.Ops(3).dms(2) := Nill; 

— op left: -> Child 
C.Ops(4).Profile := 110; 

C.Ops(4).Symbol := "left "; 

C.Ops(4).rs := 15; 

C.Ops(4).dms(l) := Nill; 

-- op right: -> Child 
C.Ops(5).Profile := 110; 

C.Ops(5), Symbol := "right "; 

C.Ops(5).rs := 15; 

C.Ops(5).dms(l):= Nill; 

— op copy .T2: Tree Tree -> Tree 
C.Ops(6).Profile :=3301; 

C.Ops(6).Symbol := "copy.T2 "; 

C.Ops(6).rs := 11; 
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C.Ops(6).dtns(l) := 11; 

C.Ops(6).dms(2) := 11; 

C.Ops(6).dms(3) := Nill; 

— op itemof; Tree -> Elt 
C.Ops(7).Profile := 220; 

C.Ops(7).Symbol ;= "itemof "; 

C.Ops(7).rs := 12; 

C.Ops(7).dms(l) := 11; 

C.Ops(7).dms(2) ;= Nill; 

— op treeisnull: -> Tree 
C.C)ps(8).Profile ;= 110; 

C.Ops(8).Symbol := "treeisnull "; 

C.Ops(8).rs ;= 11; 

C.Ops(8).dms(l):= Nill; 

— op treeisnull: -> elt 
C.C)ps(9).Profile ;= 110; 

C.Ops(9).Symbol ;= "treeisnull "; 

C.Ops(9).rs := 12; 

C.Ops(9).dms(l) := Nill; 

— op isequal: Tree Tree -> Bool 

C.Ops(10).Piofile := 3210; 
C.C)ps(10).Symbol := "isequal "; 

C.Ops(10).rs := 13; 

C.C)ps(10).dms(l) := 11; 

C.Ops(10).dms(2) := 11; 
C.Ops(10).dms(3):= Nill; 

“ op setitem.T: Elt Tree -> Tree 
C.Ops(ll).Profile := 3211; 
C.Ops(ll).Symbol := "setitem.T "; 

C.Ops(ll),rs:= 11; 

C.Ops(ll).dms(l) := 12; 
C.Ops(ll).dms(2):= 11; 

C.Ops(ll).dms(3) := Nill; 

— op childof; Child Tree -> Tree 

C.Ops(12).Profile ;= 3211; 
C.Ops(12).Symbol := "childof "; 

C.Ops(12).rs := 11; 

C.Ops(12).dms(l):= 15; 

C.Ops(12).dms(2) := 11; 

C.Ops(12).dms(3) := Nill; 

— op swapchild.Tl: Child Tree Tree -> Tree 
C.Ops(13).Profile := 4311; 
C.Ops(13).Symbol := "swapchild.Tl "; 
C.Ops(13).rs := 11; 
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C.0ps(13).dms(l):= 15; 

C.Ops(13).dms(2) := 11; 

C.Ops(13).dms(3):= 11; 

C.C^s(13).dnis(4) := Nill; 

— op swapchild.T3: Child Tree Tree -> Tree 
C.Ops(14).Profile :=4311; 

C.Ops( 14).Symbol := "swapchild.T3 "; 

C.C)ps(14).rs := 11; 

C.Ops(14).dms(l) := 15; 

C.Ops(14).dms(2) := 11; 

C.Ops(14).dms(3) := 11; 

C.Ops(14).dms(4):= Nill; 

- op construct.T: Elt Child Tree -> Tree 
C.Ops(15).Profile := 4221; 

C.Ops(15).Symbol := "construct.T "; 

C.Ops(15).rs := 11; 

C.Ops(15).dms(l):= 12; 

C.Ops(15).dms(2) := 15; 

C.O]ps(15).dms(3):= 11; 

C.Ops(15).dms(4) := Nill; 

C.Num_ops := 15; 

C.Obj_filename := ”bint2.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_Bmary__tree,Others => Nill); 
C,ProfileList:=(110,2201,220,3211,3301,3210,4311,4221,Others=>Nill); 

Stable. Sort_table( 11). Sort_Symbol: = " Tree "; 

Stable.Sort_table( 1 l).Ground_term := "null "; 

Stable.Num of sort := Stable.Num of sort + 1; 

Stable.Sort_table(l5).Sort_id := 15; 

Stable.Sort_table(l5).Sort_Symbol := "Child "; 

Stable.Sort_table(l 5).Ground_tenn := "left "; 

Stable. Sort_table( 15),Main_sort15; 

Stable. Sort_table(l 5). Sort^rank := 1; 

Stable. Sort_table( 15). Sort type := Unconfined; 

Stable. Sort_table(l 5). Csortid :=Nill; 


- Bag.obj 


When Bag_obj => 

~ put(" Working on bag_obj");new_line; 
~ op emptybag : -> Bag 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "empty "; 

C.Ops(l).rs := 11; 

C.Ops(l).dms(l):= Nill; 

- op isempty : Bag -> Bool 
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C.(^s(2).Profile ;= 220; 
C.Ops(2).Symbol := "isempty 
C.Ops(2).rs := 13; 
C.Ops(2).dms(l) := 11; 
C.Ops(2).dms(2) Nill; 

— op lengthof: Bag -> Nat 
C.C:)ps(3).Profile := 220; 
C.Ops(3).Symbol := "lengthof 
C.Ops(3).rs := 14; 
C-Ops(3).dms(l):= 11; 
C.Ops(3).dms(2) := Nill; 

— op in : Elt Bag -> Bool 
C.Ops(4).Profile := 330; 
C.Ops(4).Symbol := "in 
C.Ops(4).rs := 13; 
C.Ops(4).dms(l);= 12; 
C.Ops(4).dms(2) := 11; 
C.Ops(4).dms(3) := Nill; 

— op clear : Bag -> Bag 
C.Ops(5).Profile := 2201; 
C.Ops(5),Symbol := "clear 
C.Ops(5),rs := 11; 
C.Ops(5).dms(l) := 11; 
C.Ops(5).dms(2) := Nill; 

— op copy: Bag Bag -> Bag 
C.Ops(6).Profile := 3301; 
C.Ops(6).Symbol := "copy 
C.C)ps(6).rs := 11; 
C.Ops(6).dms(l) := 11; 
C.Ops(6).dms(2) := 11; 
C.Ops(6).dms(3) := Nill; 

— op union: Bag Bag -> Bag 
C.Ops(7).Profile := 3301; 
C.Ops(7).Symbol := "union 
C.Ops(7).rs := 11; 
C.Ops(7).dms(l) := 11; 
C.Ops(7).dms(2)11; 
C.Ops(7).dms(3) := Nill; 

— op and: Bag Bag -> Bag 
C.Ops(8).Profile :=3301; 
C.Ops(8).Symbol := "and 
C.Ops(8).rs := 11; 
C.Ops(8).dms(l) := 11; 
C.Ops(8).dms(2) := 11; 
C.Ops(8).dms(3) := Nill; 



“ op diff: Bag Bag -> Bag 
C.C)ps(9).Profile := 3301; 
C.Ops(9).Symbol := "diff 
C.C)ps(9).rs := 11; 

C.Ops(9).dnis(l) := 11, 
C.Ops(9).dms(2) := 11; 
C.Ops(9).dms(3) := Nill; 

- op UniqueExtentOf: Bag -> Nat 
C.()ps(10).Profile ;=220; 
C.Ops(10).Symbol := "uniqueExtentOf 
C.Ops(10).rs := 14; 

C.Ops(10).dms(l) ;= 11; 
C.Ops(10).dms(2):= Nill; 

- op add: Elt Bag -> Bag 

C.Ops(ll).Profile := 3211; 
C.Ops(ll),Symbol := "add "; 

C.C)ps(ll).rs := 11; 
C.Ops(ll).dms(l):= 12; 
C.Ops(ll).dms(2) := 11; 
C.Ops{ll).dms(3):= Nill; 

“ op remove: Elt Bag -> Bag 
C,Ops(12).Profile :=3211; 

C.Ops( 12). Symbol := "remove " 

C.Ops(12).rs := 11; 

C.Ops(12).dms(l) := 12; 
C.Ops(12).dms(2) := 11; 
C.Ops(12).dms(3) := Nill; 

- op NumberOf: Elt Bag -> Nat 
C.Ops(13).Profile :=330; 
C.Ops(13).Symbol := "numberOf 
C.Ops(13).rs := 14; 
C.Ops(13).dms(l):= 12; 
C.Ops(13).dms(2) := 11; 
C.Ops(13).dms(3) := Nill; 

- op singlton: Elt -> Bag 
C.Ops(14),Profile := 220; 

C.Ops( 14).Symbol := "singlton "; 

C.Ops(14).rs := 11; 

C.Ops(14).dms(l) := 12; 
C.Ops(14).dms(2) := Nill; 

-- op isequal: Bag Bag -> Bool 
C.C)ps(15).Profile := 3210; 
C.Ops(15).Symbol := "isequal "; 

C.Ops(15).rs := 13; 


C.C>ps(15).dnis(l) 11; 

C.Ops(15).dms(2) := 11; 

C.Ops(15).dms(3) := Nill; 

— op subset: Bag Bag -> Bool 
C.Ops(16).Profile := 3210; 

C. Ops( 16). Symbol: = ” subset "; 

C.Ops(16).rs:= 13; 

C.Ops(16).dms(l):- 11; 

C.Ops(16).dms(2) := 11; 

C.Ops(16).dms(3) := Nill; 

— op propersubset: Bag Bag -> Bool 
C.Ops(17).Profile := 3210; 

C.Ops(17).Symbol := "propersubset "; 

C.C)ps(17).rs := 13; 

C.Ops(l7).dms(l) := 11; 

C.Ops(17).dms(2) := 11; 

C.Ops(17).dms(3) := Nill; 

— op bagerror : -> Bag 
C.Ops(18).Profile :=110; 

C.Ops( 18).Symbol := "bagerror "; 

C.Ops(18).rs := 11; 

C.Ops(18).dms(l):= Nill; 

C.Num ops := 18; 

C.Obj_filename := "bag.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_Bag,Others => Nill); 
C.ProfileList := (110,2201,220,3211,330,3301,3210,Others => Nill); 

Stable.Sort_table( 1 l).Sort_Symbol := "Bag 

Stable. Sort_table( 1 l).Ground_term := "empty "; 


- Array.obj 


When array_obj => 

— put("Working with array_obj");New_line; 

— op Empty Array : -> Array 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "emptyArray "; 

C.Ops(l).rs := 11; 

C.Ops(l).dms(l) := Nill; 

“ op UnitArray : Elt -> Array 
C.Ops(2).Profile := 220; 

C.Ops(2).Symbol := "unitArray "; 
C.Ops(2).rs := 11; 

C.Ops(2).dms(l):- 12; 

C.Ops(2).dms(2) := Nill; 

— op AbuttedTo: Array Array -> Array 
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C.Ops(3).Profile := 3301; 
C.Ops(3).Symbol := "abuttedTo 
C.Ops(3).rs := 11; 
C.Ops(3).dms(l) := 11; 
C.Ops(3).dms(2) := 11; 
C.Ops(3).dms(3) := Mill; 

" op Copy: Array Array -> Array 
C.Ops(4).Profile ;= 3301; 
C.C)ps(4).Symbol := "copy 
C.Ops(4).rs := 11; 
C.C)ps(4).dms(l) := 11; 
C.Ops(4).dms(2) := 11; 
C.Ops(4).(lms(3) := Nill; 

- op IsEqual: Array Array -> Bool 
C,Ops(5).Profile := 3210; 
C.Ops(5).Symbol := "isEqual 
C.C)ps(5).rs := 13; 
C,Ops(5).dms(l);= 11; 
C.Ops(5).dms(2) := 11; 
C.Ops(5).dms(3) := Nill; 

-- op Isempty; Array Array -> Bool 
C.Ops(6).Profile := 3210; 

C.Ops(6).Symbol := "isempty 
C,Ops(6).rs := 13; 
C.Ops(6).dms(l) := 11; 
C,Ops(6).dms(2) := 11; 
C.Ops(6).dms(3) := Nill; 

" op Sizeof: Array -> Nat 
C.Ops(7).Profile := 220; 
C,C)ps(7).Symbol := "sizeOf 
C.Ops(7).rs := 14; 
C.Ops(7).clms(l):= 11; 
C.Ops(7).(ims(2) := Nill; 

- op Clear: Array -> Array 
C.Ops(8).Profile := 2201; 
C.Ops(8).Symbol := "clear 
C.Ops(8).rs := 11; 

C.Ops(8).dms(l) := 11; 
C.Ops(8).dms(2) := Nill; 

- op delete: Nat Array -> Bool 
C.Ops(9).Profile := 3211; 
C.Ops(9).Symbol := "delete 
C.Ops(9).rs := 13; 

C.Ops(9).dms(l) := 14; 
C.Ops(9).dms(2) := 11; 
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C.Ops(9).dms(3) ;= Nill; 


— op EltUnderflow: -> Elt 
C.Ops(lO).Profile := 110; 

C.Ops( 10).Symbol "eltUnderflow 

C.Ops(10).rs ;= 12; 

C.Ops(10).dms(l) := Nill; 

— op NatUnderflow: -> Nat 
C.Ops(ll).Profile :=110; 

C.Ops(l l).Symbol := "natUnderflow "; 

C.Ops(ll).rs:= 13; 

C.Ops(ll).dnis(l):= Nill; 

— op CopyError: -> Array 
C.Ops(12).Profile :=110; 

C.Ops( 12).Symbol := '’arrayError "; 

C.Ops(12).rs :== 11; 

C.Ops(12).dms(l):= Nill; 

— op ComponentOf: Nat Array -> Elt 
C.Ops(13).Profile :=330; 

C.Ops(l3).Symbol := "componentOf ”; 

C.Ops(13).rs := 12; 

C.Ops(13).dms(l) := 14; 

C.Ops(13).dms(2) := 11; 

C.Ops(13).dms(3) := Nill; 

C.Num_ops := 13; 

C.Obj_filename := ”array.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_Array,Others => Nill) 
C.ProfileList := (110,2201,220,3211,330,3301,3210,Others => Nill); 

Stable.Sort_table( 1 l).Sort_Symbol ;= "Array "; 

Stable. SortJable( 11).Groundjerm := "emptyarray "; 


— listl.obj. Generic version 


When listl obj => 

— put("Working on listl.obj");NewJine; 

— op nil: -> List 
C.Ops(l).Profile ;=110; 

C.Ops(l).Symbol := "nil "; 

C.Ops(l).rs := 11; 

C.Ops(l).dms(l) := Nill; 

— op isnull: List -> Bool 
C.Ops(2).Profile := 220; 

C.Ops(2).Symbol := "isnull "; 

C.Ops(2).rs := 13; - Alias to Bool sortid 4 
C.Ops(2).dms(l) := 11; 

C.Ops(2).dms(2) := Nill; 
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-- op cons. Elt List -> List 
C.C^s(3).Profile :=3211; 
C.C)ps(3). Symbol ;= "cons 
C.Ops(3).rs := 11; 
C.Ops(3).dms(l);= 12; 
C.Ops(3),dms(2) := 11; 
C.Ops(3).dms(3) := Nill; 

— op tailof: List -> List 
C.Ops(4).Profile:=2201; 
C.Ops(4).Symbol := "tailof 
C.Ops(4).rs := 11; 
C.Ops(4).dms(l).= 11; 
C.Ops(4).dms(2) := Nill; 

-- op headof: List -> Elt 
C.Ops(5).Profile := 220; 
C.Ops(5). Symbol := "headof 
C.Ops(5).rs := 12; 
C.Ops(5).dms(l):= 11; 
C.Ops(5).dms(2) := Nill; 

- op lengthof: List -> Nat 
C.Ops(6).Profile := 220; 
C.Ops(6).Symbol := "lengthof 
C.Ops(6).rs := 14; 
C.Ops(6).dms(l) := 11; 
C.Ops(6).dms(2) := Nill; 

“ op Listerror: -> List 
C.Ops(7).Profile := 110; 
C.Ops(7).Symbol ;= "listerror 
C.Ops(7).rs := 11; 
C.Ops(7).dms(l);= Nill; 

“ op clear: List -> List 
C.Ops(8).Profde := 2201; 
C.Ops(8). Symbol := "clear 
C.Ops(8).rs := 11; 
C.Ops(8).dms(l):= 11; 
C.Ops(8).dms(2) := Nill; 

" op eltenor : -> Elt 
C.Ops(9).Profile := 110; 
C.Ops(9).Symbol := "elterror 
C.Ops(9).rs := 12; 
C.Ops(9).dms(l) := Nill; 

- op copy: List List -> List 
C.Ops(10).Profile:= 3301; 




C.Ops(10).Symbol := "copy 
C,Ops(10).rs := 11; 

C,Ops(10).dms(l) := 11; 

C.Ops(10).dms(2) := 11; 

C.Ops(10).dms(3) := Nill; 

- op clearhead: List -> List 
C.Ops(ll).Pir)file:= 2201; 

C.Ops(l l).Symbol := "clearhead 
C.Ops(ll).rs:= 11; 

COps(ll).dms(l):= 11; 

C.Ops(ll).dms(2) ;= Nill; 

-- op contains: Elt List -> Bool 
C.Ops(12).Profile := 330; 

C. Ops( 12). Symbol := "contains "; 

C.Ops(12).rs := 13; 

C.Ops(12).dms(l);= 12; 

C.Ops(12).dms(2) := 11; 

C.Ops(12).dms(3) := Nill; 

— op sethead: Elt List -> List 
C.Ops(13).Profile:= 3211; 

C.Ops(13).Symbol := "sethead "; 

C.Ops(13).rs := 11; 

C.Ops(13).dms(l);= 12; 

C.Ops(13).dms(2):= 11; 

C.Ops(13).dms(3) ;= Nill; 

“ op isequal: List List -> Bool 
C.Ops(14).Piofile := 3210; 

C.C)ps( 14).Symbol := "isequal 
C.Ops(14).rs:= 13; 

C.C)ps(14).dms(l) ;= 11; 

C.Ops(14).dms(2) := 11; 

C.Ops(14).dms(3) := Nill; 

C.Num_ops := 14; 

C.Obj_filename := "listl.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_List,Others=> Nill); 
C.ProfileList ;= (110,2201,220,321 l,330,3301,3210,0thers => Nill); 
Stable.Sort_table(l l).Sort_Symbol := "List "; 

Stable. Sort_table( 1 l).Ground_term := "nil 


— list2.obj Natural List 


When List2_obj => 

— put("Working on List2. obj");New_line; 

— op nit : -> List 
C.Ops(l).Profile:= 110; 
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C.C^s(l).Symbol ;= "nil 
C.Ops(l).rs := 11; 

C.Ops(l).dms(l);= Nill; 

“ op isnull: List -> Bool 
C.C)ps(2).Profile ;= 220; 

C.C)ps(2).Symbol := "isnull "; 

C.C>ps(2).rs := 13; -- Alias to Bool sortid 4 
C.Ops(2).dms(l):= 11; 

C.Ops(2).dms(2) ;= Nill; 

— op cons: Nat List -> List 
C.Ops(3).Profile := 3211; 

C.Ops(3).Symbol := "cons "; 

C.Ops(3).rs := 11; 

C.Ops(3).dms(l):= 14; 

C.Ops(3).dms(2) ;= 11; 

C.Ops(3).dms(3) := Nill; 

“ op tailof: List -> List 
C.Ops(4).Profile := 2201; 

C.Ops(4).Symbol := "tailof "; 

C.Ops(4).rs := 11; 

C.Ops(4).dms(l) := 11; 

C.C)ps(4).dms(2) := Nill; 

— op headof: List -> Nat 
C.Ops(5).Profile := 220; 

C.Ops(5). Symbol := "headof 
C.Ops(5).rs := 14; 

C.Ops(5).dms(l):= 11; 

C.Ops(5).dms(2) := Nill; 

-- op lengthof: List -> Nat 
C.Ops(6).Profile := 220; 

C.Ops(6).Symbol := "lengthof "; 
C.Ops(6).rs := 14; 

C.Ops(6).dms(l) := 11; 

C.Ops(6).dms(2) := Nill; 

-- op Listerror: -> List 
C.Ops(7).Profile := 110; 

C.Ops(7).Symbol := "listerror "; 
C.Ops(7).rs := 11; 

C.Ops(7).dms(l) := Nill; 

— op clear: List -> List 
C.Ops(8).Profile:=2201; 

C.Ops(8).Symbol := "clear "; 

C.Ops(8).rs := 11; 

C.Ops(8).dms(l) := 11; 
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C.Ops(8).dnis(2) := Nill; 

- op elterror : -> Nat 
C.C)ps(9).Profile := 110; 

C.Ops(9).Symbol ;= "elterror 
C.Ops(9).rs ;= 14; 

C.Ops(9).dms(l) := Nill; 

- op copy: List List -> List 
C.C)ps(10).Pn)file:=3301; 

C.Ops(10).Symbol := "copy "; 

C.Ops(10).rs:= 11; 

C.Ops(10).dms(l):= 11; 

C.Ops(10).dms(2) := 11; 

C.Ops(10).dms(3) := Nill; 

“ op clearhead: List -> List 
C.Ops(ll).Profile :=2201; 

C.Ops(l l).Symbol := "clearhead "; 

C.Ops(ll).rs:= 11; 

C.C)ps(l l).dms(l) := 11; 

C.Ops(ll).dms(2):= Nill; 

- op contains: Nat List -> Bool 
C.Ops(12).Profile := 330; 

C.Ops( 12).Symbol := "contains "; 

C.Ops(12).rs := 13; 

C.Ops(12).dms(l) := 14; 

C.Ops(12),dms(2):= 11; 

C.Ops(12).dms(3) := Nill; 

- op sethead: Nat List -> List 
C.Ops(13).Profile:=3211; 

C.Ops(13).Symbol := "sethead "; 

C,Ops(13),rs := 11; 

C.Ops(13).dms(l) := 14; 

C.Ops(13).dms(2) := 11; 

C.Ops(13).dms(3) := Nill; 

- op isequal: List List -> Bool 
C,Ops(14).Profile := 3210; 

C.Ops(14).Symbol := "isequal "; 

C.Ops(14).rs := 13; 

C.Ops(14).dms(l):= 11; 

C.Ops(14).dms(2) := 11; 

C.Ops(14).dms(3) := Nill; 

C.Num ops := 14; 

C.Obj_filename := "list2.obj "; 

C.KeywordList := (Kw_BoochjCw_DataStructure,Kw_List,Others => Nill); 
C.ProfileList := (110,2201,220,3211,330,3301,3210,Others => Nill); 
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Stable.Sort_table( 1 l).Sort_Symbol := "List 
Stable. SortJable( I l).Ground_term "nil 


- deque, obj 


When deque_obj => 

— put("Working with deque.obj"); Newsline; 

— op empty : -> deque 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol.- "empty "; 

C.Ops(l).rs:= II; 

C.Ops(l).dms := (Others => Nill); 

— op underflow : -> deque 
C.Ops(2).Profile := 110; 

C.Ops(2).Symbol := "underflow "; 
C.Ops(2).rs := 11; 

C.Ops(2).dms := (Others => Nill); 

— op underflow : -> elt 
C.Ops(3).Profile := 110; 

C.Ops(3).Symbol := "underflow 
C.Ops(3).rs := 12; 

C.Ops(3).dms := (Others => Nill); 

— op Front: -> Location 
C.Ops(4).Profile := 110; 

C.Ops(4).Symbol := "front "; 

C.Ops(4).rs := 15; 

C.Ops(4).dms := (Others => Nill); 

— op Back : -> Location 
C.Ops(5).Profile 110; 

C.Ops(5). Symbol := "back 
C.Ops(5).rs := 15; 

C.Ops(5).dms := (Others => Nill); 

— op isempty: Deque -> Bool 
C.Ops(6).Profile220; 

C.Ops(6).Symbol := "isempty "; 

C.Ops(6).rs := 13; 

C.Ops(6),dms := (1 l,Others => Nill); 

— op clear: deque -> deque 
C.Ops(7).Profile := 2201; 

C.Ops(7).Symbol := "clear "; 

C.Ops(7).rs := 11; 

C.Ops(7).dms := (11, others => Nill); 

— op lengthof: deque -> Nat 
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C.0ps(8).Profile ;= 220; 

C.Ops(8).Symbol := "lengthof ", 

C.Ops(8).rs := 14; 

C.Ops(8).dms := (11, others => Nill); 

“ op frontof: deque -> Elt 
C.C)ps(9),Profile := 220; 

C.Ops(9).Symbol := "frontof "; 

C,Ops(9).rs := 12; 

C.Ops(9).dms := (11, others => Nill); 

- op backof; deque -> Elt 
C.(^(10).Profile := 220; 

C.Ops(10).Symbol := "backof "; 

C Ops(10).rs •= 12; 

C.Ops(lO) dms := (1 i, others => Nill); 

“• op isequal: deque deque -> Bool 
C.Ops(i l).Pn)fik 1210; 

C.Ops( (I ).Symbol ;= "isequal "; 

C.Ops(ll).rs:= 13; 

C.Ops(ll).dms := (11,1 l,others=> Nill); 

“ op copy: deque deque -> deque 
C.Ops(12).PrDfile := 3301; 

C.Ops(12).Symbol := "copy "; 

C.Ops(12).rs := 11; 

C.Ops(12).dms := (11,1 l,others=> Nill); 

-- op pop: location deque -> deque 
C.Ops(13).Profile := 3211; 

C.Ops(13).Symbol := "pop "; 

C.Ops(13).rs := 11; 

C.Ops(13).dms := (15,1 l,others => Nill); 

— op add: Elt location deque -> deque 
C.Ops(14).Profile:=4221; 

C.Ops( 14).Symbol := "add ", 

C.C»ps(14).rs := 11; 

C.Ops(14).dms := (12,15,1 l,olhers=> Nill), 

C.Num ops := 14; 

C.Obj_filename := "deque.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_Deque,Others => Nill); 
C.ProfileList := (110,2201,220,3211,3301,3210,421 l,Others => Nill); 
Stable.Sort_table(ll).Sort_Symbol := "Deque "; 

Stable.Sort_table(ll).Ground_term := "empty "; 

Stable Num_of_sort := Stable.Num_of_sort + 1; 

Stable.Sort_table(15).Sort_id := 15; 

Stable. Sort_table(l 5). Sort_Symbol := "Location "; 
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Stable. Sort_table(l 5). Ground_term := "front 
Stable.Sort_table(15),Main_sort := 15; 

Stable. SortJable(l 5). Sort_rank := 1; 

Stable. Sort_tabIe( 15). Sort_type := Unconfined; 
Stable.Sort_table(15).Csortid :=Nill; 

Stable.Sort_table( 15).Childrenjds(l) := Nill; 


— Bintl.obj, Binary Tree Obj version one. 


When Bintl_obj => 

— put("Working with binary tree version one"); Newjine; 

— op empty : -> bintree 
C.Ops(l).Profile :=110; 

C.Ops(l).Symbol := "empty "; 

C.Ops(l).rs:= 11; 

C.Ops(l).dms(l) := Nill; 

— op isempty; bintree -> Bool 
C.Ops(2).Profile := 220; 

C.Ops(2).Symbol := "isempty "; 

C.Ops(2).rs := 13; -- Alias to Bool sortid 4 
C.Ops(2).dms(i) := 11; 

C.Ops(2).dms(2) := Nill; 

— op node : bintree -> elt 
C.Ops(3).Profile := 220; 

C.Ops(3).Symbol := "node "; 

C.Ops(3).rs := 12; 

C.Ops(3).dms := (11,Others => Nill); 

— op left: bintree -> bintree 
C.Ops(4).Profile :=2201; 

C.Ops(4).Symbol := "left "; 

C.Ops(4).rs := 11; 

C.Ops(4).dms(l) := 11; 

C.Ops(4).dms(2) := Nill; 

op right: bintree -> bintree 
C.Ops(5).Profile :=2201; 

C.Ops(5).Symbol := "right "; 

C.Ops(5).rs := 11; 

C.Ops(5).dms(l) := 11; 

C.Ops(5).dms(2) := Nill; 

— op height: bintree -> Nat 
C.Ops(6).Profile := 220; 

C.Ops(6).Symbol := "height "; 

C.Ops(6).rs := 14; 

C.Ops(6).dms := (11,Others => Nill); 
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— op isin: Elt bintree -> Bool 
C.Ops(7).Profile := 330; 

C.Ops(7).Symbol := ’’isin 
C.Ops(7).rs := 13; 

C.Ops(7).clms := (12,11,Others => Nill); 

— op naterror : -> Elt 
C.Ops(8).Profile := 110; 

C.Ops(8).Symbol := ’’naterror "; 

C.Ops(8).rs := 12; 

C.Ops(8).dms := (Others => Nill); 

— op make: Elt bintree bintree -> bintree 
C.Ops(9).Profile := 4311; 

C.Ops(9).Symbol := ’’make "; 

C.Ops(9).rs := 11; 

C.Ops(9).dms := (12,11,11,Others ==> Nill); 

C.Num_ops := 9; 

C.Obj_filename := "bintl.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_BinaiyJree,Others => Nill); 
C.ProfileList := (110,2201,220,330,4311,Others => Nill); 

Stable.Sort_table( 1 l).Sort_Symbol := "Tree 

Stable, SortJable( 11), Groundjerm := " empty "; 


— Set.obj 


When set_obj => 

— put(”Working on set__obj”); Newjine; 

— op create : -> set 
C,Ops(l).Profile:= 110; 

C.Ops(l).Symbol :== ’’create ”; 

C.Ops(l).rs := 11; 

C.Ops(l).dms(l) := Nill; 

— op isempty: set -> Bool 
C.Ops(2).Prorile := 220; 

C.Ops(2).Symbol := ’’isempty ”; 

C.Ops(2).rs :== 13; - Alias to Bool sortid 4 
C.Ops(2).dms(l) := 11; 

C.Ops(2).dms(2) := Nill; 

— op add: Elt set -> set 
C.Ops(3).Prome :=3211; 

C.Ops(3).Symbol := ’’add ”; 

C.Ops(3).rs := 11; 

C.Ops(3).dms(l) := 12; 

C.Ops(3).dms(2) := 11; 

C.Ops(3).dms(3) := Nill; 

— op clear: set -> set 
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C.Ops(4).Profile := 2201; 
C.Ops(4).Synibol := "clear 
C.Ops(4).rs := 11; 
C.Ops(4).dms(l) := 11; 
C.Ops(4).dms(2) ;= Nill; 

— op cardinality: set -> Nat 
C.Ops(5).Profile ;= 220; 
C.Ops(5). Symbol := "cardinality 
C.Ops(5).rs := 14; 
C.Ops(5).dms(l):= 11; 
C.Ops(5).dms(2) := Nill; 

— op seterror: -> set 
C.Ops(6).Profile := 110; 
C.Ops(6).Symbol ;= "seterror 
C.Ops(6).rs := 11; 
C.Ops(6).dms(l) := Nill; 

— op copy: set set -> set 
C.Ops(7).Profile := 3301; 
C.Ops(7).Symbol := "copy 
C.Ops(7).rs := 11; 
C.Ops(7).clms(l) := 11; 
C.Ops(7).dms(2) := 11; 
C.Ops(7).dms(3) := Nill; 

" op union: set set -> set 
C.Ops(8).Profile := 3301; 
C.Ops(8).Symbol := "union 
C.C)ps(8).rs := 11; 
C.Ops(8).dms(l) := 11; 
C.Ops(8).clms(2) := 11; 
C.Ops(8).dms(3) := Nill; 

— op intersection: set set -> set 
C.C)ps(9).Profile := 3301; 
C.Ops(9). Symbol := "intersection 
C.C)ps(9).rs := 11; 
C.Ops(9).dms(l) := 11; 
C.Ops(9).dms(2) := 11; 
C.Ops(9).dms(3) := Nill; 

— op remove: Elt set -> set 
C.Ops(10).Profile := 3211; 

C.Ops( 10).Symbol := "remove 
C.Ops(10).rs := 11; 
C.Ops(10).dms(l):= 12; 
C.Ops(10).dms(2) := 11; 
C.Ops(10).dms(3) := Nill; 



— op isequal. set set -> Bool 
C.Ops(ll).Profile :=32]0; 

C.Ops(l 1).Symbol := "isequal 
C.Ops(ll).rs:= 13; 

C.Ops(ll).dms(l);= 11; 

C.Ops(ll).dms(2):= 11; 

C.Ops(ll).dms(3);= Nill; 

— op subsetof: set set -> Bool 
C.Ops(12).Profile :=3210; 

C.C)ps(12).Symbol := "subsetof 
C.Ops(12).rs ;= 13; 

C.Ops(12).dms(l) ;= 11; 

C.Ops(12).dms(2) := 11; 

C.Ops(12).dms(3) ;= Nill; 

— op prosubsetof: set set -> Bool 
C.Ops(13).Profile :=3210; 

C.Ops(13).Symbol := "prosubsetof "; 

C.Ops(13).rs := 13; 

C.Ops(13).dms(l) := 11; 

C.Ops(13).dms(2) ;= 11; 

C.Ops(13).dms(3) := Nill; 

-- op memberof: Elt Set -> Bool 
C.Ops(14).Piofile := 330; 

C.C)ps(14).Symbol := "memberof "; 

C.Ops(14).rs := 13; 

C.Ops(14).dms(l) := 12; 

C.Ops(14).dms(2) := 11; 

C.Ops(14).dms(3) := Nill; 

C.Num ops := 14; 

C.Obj_filename := "set obj "; 

C.KeywordList ;= (Kw_Booch,Kw_DataStructure,Kw_Set,Others => Nill); 
C.ProfileList ;= (110,2201,220,3211,3210,330,3301,Others => Nill); 

Stable.Sort_table( 1 l).Sort_Symbol := "Set "; 

Stable.Sort_table(ll).Ground_term := "create "; 


— stackl.obj 


When Stack l_obj => 

— putC’Working on Stacklobj"); Newline; 
-- op create: -> Stack 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "create "; 

C.Ops(l).rs := 11; 

C.Ops(l).dms(l):= Nill; 

“ op isempty: Stack -> Bool 
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C.Ops(2).Profile := 220; 

C.C)ps(2).Symbol := "isempty 
C.C)ps(2).rs := 13;-- Alias to Bool sortid 4 
C.C>ps(2).dms(l) := 11; 

C.Ops(2).dms(2) := Nill; 

- op push; Elt Stack -> Stack 
C.Ops(3).Profile:=3211; 

C.C)ps(3). Symbol := "push 
C.Ops(3).rs := 11; 

C.Ops(3).dms(l) := 12; 

C.C)ps(3).dms(2) := 11; 

C.Ops(3).dms(3) := Nill; 

- op pop: Stack -> Stack 
C.Ops(4).Profile := 2201; 

C.Ops(4). Symbol := "pop "; 

C.Ops(4).rs := 11; 

C.Ops(4).dms(l):= 11; 

C.Ops(4).dms(2) := Nill; 

- op top: Stack -> Elt 
C.Ops(5).Profile := 220; 

C.Ops(5).Symbol ;= "top "; 

C.Ops(5).rs := 12; 

C.Ops(5).dms(l) := 11; 

C,Ops(5).dms(2) := Nill; 

- op stacksize: Stack -> Nat 
C.C)ps(6).Profile := 220; 

C.Ops(6).Symbol := "stacksize "; 

C.C)ps(6).rs := 14; 

C.Ops(6).clms(l) ;= 11; 

C.Ops(6).dms(2) := Nill; 

" op emptyerror: -> Stack 
C.Ops(7).Profile ;= 110; 

C.Ops(7). Symbol := "emptyerror "; 

C.Ops(7).rs := 11; 

C.Ops(7).clms(l):= Nill; 

- op clear: stack -> Stack 
C.Ops(8).Profile := 2201; 

C.Ops(8). Symbol ;= "clear "; 

C.C)ps(8).rs := 11; 

C.Ops(8).dms(l);= 11; 

C.Ops(8).dms(2) ;= Nill; 

C.Num ops := 8; 

C. Obj filename :== " stack 1 obj "; 

C.Kq^wordList := (Kw_Booch,Kw_DataStructure,Kw_Stack,Others => Nill); 
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C.ProfileList := (220,2201,110,3211,Others => Nill); 
Stable.Sort_table( 1 l).Sort_Symbol "Stack 
Stable.Sort_table( 1 l).Ground_term := "create 


- queue, obj 


When queue_obj => 

— put(" Working on queue"); Newsline; 

— op empty: -> queue 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "empty 
C.Ops(l).rs := 11; 

C.Ops(l).dms(l):= Nill; 

— op pop.Q : queue -> queue 

C.Ops(2).Profile := 2201; 
C.Ops(2).Symbol := "pop.Q "; 

C.Ops(2).rs := 11; 

C.Ops(2).dms(l):= 11; 

C.Ops(2).dms(2)Nill; 

— op add.Q: Elt queue -> queue 
C.Ops(3).Profile :=3211; 

C.Ops(3).Symbol := "add.Q "; 

C.Ops(3).rs := 11; 

C.Ops(3).dms(l) := 12;--Elt generic sort 
C.Ops(3)-dms(2) := 11; 

C.Ops(3).dms(3) := Nill; 

— op frontof: queue -> elt 
C.Ops(4).Profile := 220; 

C.Ops(4).Symbol := "frontof "; 

C.Ops(4).rs := 12; 

C.Ops(4).dms(l):- 11; 

C.Ops(4).dms(2) Nill; 

— op isempty. queue -> Bool 
C.Ops(5).Profile := 220; 

C.Ops(5).Symbol := "isempty 
C.Ops(5).rs := 13; -- Alias to 4 for Bool 
C.Ops(5).dms(l) := 11; 

C.Ops(5).dms(2) := Nill; 

— op underflow: -> queue 
C.Ops(6).Profile := 110; 

C.Ops(6). Symbol := "underflow "; 
C.Ops(6).rs := 11; 

C.Ops(6).dms(l):= Nill; 

— op underflow: -> Elt 
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C.Ops(7).Profile := 110; 

C.C)ps(7).Symbol := "underflow 
C.Ops(7).rs := 12; 

C.Ops(7).dms(l):= Nill; 

- op lengthof. queue -> Nat 
C.Ops(8).Profile := 220; 

C.Ops(8).Symbol := "lengthof 
C.Ops(8).rs := 14; 

C.Ops(8).dms(l):= 11; 

C.Ops(8).dms(2) := Nill; 

“ op isequal: queue queue -> Bool 
C.Ops(9),Profile := 3210; 

C.Ops(9).Symbol := "isequal ", 

C.Ops(9).rs := 13; 

C.Ops(9).dms(l) := 11; 

C.C)ps(9).dms(2) := 11; 

C.Ops(9).dms(3) := Nill; 

” op copy.Q2: queue queue -> queue 
C.Ops(10).Pix)file := 3301; 

C.Ops(10).Symbol := "copy.Q2 "; 

C.Ops(10).rs := 11; 

C.Ops(10).dms(l) := 11; 

C.Ops(10).dms(2) := 11; 

C.Ops(10).dms(3) ;= Nill; 

" op clear. Q : queue -> queue 
C.Ops(ll).Piofile;= 2201; 

C.Ops(ll).Symbol := "clear.Q "; 

C.Ops(ll).rs := 11; 

C.Ops(ll).dms(l):= 11; 

C.Ops(ll).dms(2):= Nill; 

C.Num ops := 11; 

C.Obj_filename := "queue.obj "; 

C.ProfileList := (110,2201,220,3211,3301,3210.Others => Nill); 
C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_Queue,Otliers=> Nill); 
Stable.Sort_table(l l).Sort_Symbol := "Queue "; 

Stable.Sort_table(l l).Ground_tenn := "empty "; 


-- stack2.obj 


When others => 

— put("Working on stack2_obj"); New_line; 

- op create: -> Stack 
C.Ops(l).Profile := 110; 

C.Ops(l).Symbol := "create "; 

C.OpsCQ.rs := 11; 
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C.Ops(l).(ims(l) := Nill; 

- op isempty: Stack -> Bool 
C.Ops(2).Profile := 220; 

C.Ops(2).Symbol := "isempty 
C.Ops(2).rs := 13; - Alias to Bool sortid 4 
C.C)ps{2).dms(l) := 11; 

C.Ops(2).dms(2) := Nill; 

- op push: Elt Stack -> Stack 
C.C)ps(3).Profile :-3211; 

C.Ops(3).Symbol := "push "; 

C.Ops(3).rs := 11; 

C.Ops(3).dms(l):= 12; 

C.Ops(3),dms(2) := 11; 

C.Ops(3).dms(3) := Nill; 

- op pop: Stack -> Stack 
C.Ops(4).Profile := 2201; 

C.Ops(4).Symbol := "pop "; 

C.Ops(4).rs := 11; 

C.Ops(4),dms(l):= 11; 

C.Ops(4).dms(2) := Nill; 

- op top: Stack -> Elt 
C.Ops(5).Profile := 220; 

C.Ops(5).Symbol := "top "; 

C.Ops(5).rs := 12; 

C.Ops(5).dms(l) := 11; 

C.Ops(5).dms(2) := Nill; 

- op depthof: Stack -> Nat 
C.Ops(6).Profile := 220; 

C.Ops(6).Symbol := "depthof "; 

C.Ops(6).rs := 14; 

C.Ops(6).dms(l) := 11; 

C.Ops(6).dms(2) := Nill; 

- op copy: Stack Stack -> Stack 
C.Ops(7).Profile := 3301; 

C.Ops(7).Symbol := "copy "; 

C,Ops(7).rs := 11; 

C.Ops(7).dms(l):= 11; 

C.Ops(7).dms(2) := 11; 

C.Ops(7).dms(3) := Nill; 

- op clear: stack -> Stack 
C.Ops(8).Profile :=2201; 

C.Ops(8).Symbol := "clear 
C.Ops(8).rs := 11; 

C.Ops(8).dms(l):= 11; 
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C.Ops(8).dms(2) := Nill; 


“ op empty : -> Stack 
C.Ops(9).Profile := 110; 

C.Ops(9).Symbol := "empty 
C.Ops(9).m:= 11; 

C.Ops(9).dms(I):= Nill; 

- op StackError : -> Stack 
C.Ops(10).Profile := 110; 

C.Ops( 10).Symbol := "StackError "; 

C.Ops(10).rs := 11; 

C.Ops(10).dms(l):= Nill; 

- op StackError : -> Elt 
C.Ops(ll).Pix)file :=110; 

C.Ops(ll).Symbol := "StackError "; 

C.Ops(ll).rs := 12; 

C.Ops(ll).dms(l):= Nill; 

- op isequal: Stack Slack -> Bool 
C.Ops(12).Profile := 3210; 

C Ops( 12).Symbol := "isequal "; 

C.Ops(12).rs := 13; 

C.Ops(12).dms(l):= 11; 

C.Ops(12).dms(2) := 11; 

C.Ops(12).dms(3):= Nill; 

C.Num_ops := 12; 

C.Obj filename := "stack2.obj "; 

C.KeywordList := (Kw_Booch,Kw_DataStructure,Kw_Stack,Others => Nill); 
C.ProfileList := (220,2201,110,3211,3301,3210,Others -> Nill); 

Stable. Sort_table( 11). Sort_Symbol := " Stack "; 

Stable.Sort_table( 1 l).Groiind_term := "create "; 

End Case; 

— Now, common sorts Initialization 

Stable.Num_of_sort := Stable.Num_of_sort + 1; 

Stable.Sort_table(l 1 ).Sort_id := 11; 

Stable.Sort_table(l l).Main_sort := 11; 

Stable.Sort_table(ll).Sort rank := 1; 

Stable.SortJable(l l).Sort_type := Unconfined; 

Stable.SortJable(l l).Csortid := Nill; 

Stable.Sort_table(l l).Children_ids(l) := Nill; 

Stable. Sort Jable(l l).Parent ids(l) := Nill; 

Stable.Num_of_sort := Stable.Num_of_sort + 1; 

Stable.SortJable(12).SortJd := 12; 

Stable. SortJable( 12). Sort^Symbol := "Elt "; 

StabIe.SortJable(12).Main_sort12; 

Stable.Sort_table(12).Sort_rank := 1; 
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Stable. Sort_table(l 2). Sort_type := Unconfined; 

Stable.Sort_table(12),Csortid := Nill; 

Stable.SortJable(12).Children_ids(l) Nill; 

Stable.SortJable(12).Parent_ids(l) := Nill; 

Stable.Num_of_sort := Stable.Num_of_sort + 1; 

Stable.SortJable( 13) := Stable.Sort_table(Bool_type); - Alias to bool 

Stable.Nuni_of_sort := Stable.Nuni__of_sort + 1; 

Stable,SoTtJable( 14) := Stable.Sort_table(Nat_type); - Alias to nat 

KwRank := KeywordRank(Q,C); 

PrfRank := ProfileRank(Q,C); 

End InitComponentData; 

Function LookupBlockIndex(Pindex: Natural) return Integer is 
Profile_table : Array (0.-18) of Integer := 

(0,110,2201,220,321 l,330,3301,3210,4311,422UNill,11,12,13,14,15,16,17,18); 

Begin 

Fori in0..18 
Loop 

If Profile_table(i) = Pindex then 
Return i; 

End If; 

End Loop; 

Retum(Nill); 

End LookupBlockIndex; 

Procedure UpdateCandidatesTable(Candidates: Out CandidatesTable; 

H : In Out Hasse_diagram_type;node. Integer;Eoa: In Out 
Natural) is 

Begin 

- Get component(s) in current node 
Fori in L.ComponentJd listLength 
Loop 

If H(LookupBlocklndex(node)).Component_list(i) /= Nill then 
Candidates(Eoa).ComponentId := H(LookupBlockIndex(node)).ComponenMist(i); 
Eoa :=Eoa + 1; 

Else 

Candidates(Eoa).ComponentId := Nill; 

Exit; 

End If; 

End Loop; 

H(LookupBlockIndex(node)). Visit := True; — Mark node visit 

— now get component in children nodes 
Fori in l..Children_id_list'Length 
Loop 

If H(LookupBlockIndex(node)).Children_list(i) /= Nill then 
Forj in L.Component id lisfLength 
Loop 
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If H(LookupBlockIndex(H(LookupBlockIndex(node)).ChildrenJist(i))).Visit = False then 
If 

H(LookupBlockIndex(H(LookupBlockIndex(node)).ChildrenJist(i))).Component_List(j) 

/= Nill then 

Candidates(Eoa).ComponentId := 

H(LookupBlockIndex(H(LookupBlockIndex(node)).Children_list(i))).Component_List(j); 

Eoa := Eoa + 1; 

Else 

Candidates(Eoa).ConiponentId := Nill; 

Exit; 

End If; 

End If; 

End Loop; 

If H(LookupBlockIndex(H(LookupBlockIndex(node)).Children Jist(i))). Visit = False then 

H(LookupBlockIndex(H(LookupBlockIndex(node)), ChildrenJist(i))). Visit := True; 

End If; 

End If; 

End Loop; 

End UpdateCandidatesTable; 

Procedure FindCandidateComponents(Q: In Out Qc; Candidates: In Out 
CandidatesTable; Profile err: Out Profile err_list) is 

H : Hasse_diagram_type; 
m : Natural := 1; 

Eoa : Natural ;= 1; 

Begin 

— Check for valid frequency in each test cases 
Fori in L.Q.Num tcases 

Loop 

Forj in L.ProfileList_defLength 
Loop 

If Q.Geq(i).ProfileList(j) /= Nill Then 
If LookupBiockIndex(Q.Geq(i).ProfileList(j)) = Nill then 
Profile_err(m) := Q.Geq(i).ProfileList(j); 
m :=m + 1; 

Profile_err(m) := Nill; 

Q.Geq(i). Status := Void; 

End If; 

End If; 

End Loop; 

End Loop; 

— Initialize Basse diagram with components from CS4520 course 
lntializeSwb(H); 

— Now, start searching 

PeformDfsfw(H,Q,RootNode,C andidates,Eoa); 

End FindCandidateComponents; 

Function DetermineProfileIntersection(GeqProfile:ProfiIelist_def; Pprofile: 

Profile Jd list) Return Boolean is 
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Found : Boolean; 

Begin 

Fori in L.Profilelist_defLength 
Loop 

Found := False; 

If GeqProfile(i) /= Nill then 
Forj in 1. .Profile_idJist'Length 
Loop 

If GeqProfile(i) == Pprofile(j) then 
Found := True; 

Exit; 

End If; 

End Loop; 

If Found = False then 
Return False; 

End If; 

Else 

Exit; 

End If; 

End Loop; 

Return True; 

End DetermineProfileIntersection; 

Procedure PeformDfsfw(H: In Out Hasse_diagram_type;Q: Qc; node: Integer; 

Candidates: Out CandidatesTable;Eoa : In Out Natural) is 

Begin 

H(LookupBlockIndex(node)). Visit := True; - Mark node visit 

Forj in L.Q.Num tcases 

Loop 

If Q.Geq(j).Status /= Void then 
If DetennineProfileIntersection(Q.Geq(j ).ProfileList, 

H(LookupBlockIndex(node)).Profile_List) then 

UpdateCandidatesTable(Candidates,H,node,Eoa); 

Exit; 

End If; 

End If; 

End Loop; 

Forj in L.ChiIdren_id_list'Length 
Loop 

If H(LookupBlockIndex(node)).Children_list(j) /= Nill then 
If H(LookupBlockIndex(H(LookupBlockIndex(node)).Children_list(j))). Visit = False then 

PeformDfsfw(H,Q,H(LookupBlockIndex(node)).Children_list(j),Candidates,Eoa); 

End If; 

End If; 

End Loop; 

End PeformDfsfw; 

Procedure IntializeSwb(H : In Out Hasse_diagram_type) is 
Begin 
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— Root node 

H(LookupBlockIndex(0)).Pipro := True; 

H(LookupBlockIndex(0)). Visit := False; 

~ No need to put all children for pi prime node 
H(LookupBlockIndex(0)).Children^list:= 

(110,2201,220,3211,330,3301,3210,4311,4221,Others => Nill); 
H(LookupBlockIndex(0)).Component Jist (Others => Nill); 
H(LookupBlockIndex(0)).ProfileJist := (0,Others => Nill); 

— -> A profile , P1 

H(LookupBlockIndex(l 10)).Pipro := True; 

H(LookupBlockIndex(l 10)). Visit := False; 

— No need to put all children for pi prime node 
H(LookupBlockIndex(l 10)).ChildrenJist := (12,17,Others => Nill); 
H(LookupBlockIndex(l 10)).ComponentJist := (Others => Nill); 
H(LookupBlockIndex(l 10)XProfileJist := (110,Others => Nill); 

-- A -> A profile, P2 

H(LookupBlockIndex(2201)).Pipro := True; 
H(LookupBlockIndex(2201)). Visit := False; 

No need to put all children for pi prime node 
H(LookupBlockIndex(2201)).ChildrenJist := (12,17,Others => Nill); 
H(LookupBlockIndex(2201)),Component list := (Others => Nill); 
H(LookupBlockIndex(2201)).Profile_list := (2201,Others => Nill); 

“ A -> B profile, P3 

H(LookupBlockIndex(220)).Pipro := True; 
H(LookupBlockIndex(220)). Visit := False; 

— No need to put all children for pi prime node 
H(LookupBlockIndex(220)).Children_list := (12,17,Others => Nill); 
H(LookupBlockIndex(220)).ComponentJist (Others => Nil}); 
H(LookupBlockIndex(220)),ProfileJist := (220,Others => Nill); 

— A B -> A profile, P4 
H(LookupBlockIndex(321 l)).Pipro := True; 
H(LookupBlockIndex(3211)). Visit := False; 

— No need to put all children for pi prime node 
H(LookupBlockIndex(3211)). ChildrenJist := (12,Others => Nill); 
H(LookupBlockIndex(321 l)).Component_list := (Others => Nill); 
H(LookupBlockIndex(321 l)).Profile_list := (3211,Others => Nill); 

— A B -> C profile, P5 
H(LookupBlockIndex(330)).Pipro := True; 
H(LookupBlockIndex(330)). Visit := False; 
H(LookupBlockIndex(330)).Children list := (14,17,Others => Nill); 
H(LookupBlockIndex(330)).Component_list := (Others => Nill); 
H(LookupBlockIndex(330)).ProfileJist := (330,Others => Nill); 

“ A A -> A profile, P6 
H(LookupBlockIndex(3301)).Pipro := True; 
H(LookupBlockIndex(3301)). Visit := False; 
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- No need to put all children for pi prime node 
H(LookupBIockIndex(3301)).ChildrenJist := (14,Others => Nill); 
H(LookupBlockIndex(3301)).Component_list := (Others => Nill); 
H(LookupBlockIndex(3301)).ProfileJist ;= (3301,Others => Nill); 

- A A -> B profile, P7 
H(LookupBlockIndex(3210)).Pipro := True; 

H(LookupBlockIndex(3210)). Visit := False; 

- No need to put all children for pi prime node 
H(LookupBlockIndex(3210)). Children Jist := (13,Others => Nill); 

H(LookupBlockIndex(3210)). Component Jist := (Others => Nill); 
H(LookupBlockIndex(3210)).ProfileJist := (3210,Others => Nill); 

- A B B -> B profile, P8 
H(LookupBlockIndex(431 l)).Pipro := True; 

H(LookupBlockIndex(4311)). Visit := False; 

- No need to put all children for pi prime node 
H(LookupBlockIndex(4311)). Children Jist := (18,Others => Nill); 

H(LookupBlockIndex(431 l)).Component list := (Others => Nill); 

H(LookupBlockIndex(431 l)).ProfileJist := (4311,Others => Nill); 

- A B C -> B profile, P9 
H(LookupBlockIndex(4221 )).Pipro := True; 

H(LookupBlockIndex(4221)). Visit := False; 

- No need to put all children for pi prime node 
H(LookupBlockIndex(4221)). Children Jist := (16,Others => Nill); 
H(LookupBlockIndex(4221)).ComponentJist := (Others => Nill); 
H(LookupBlockIndex(4221)).ProfileJist := (4221,Others => Nill); 

- Profile index 1,2,3,4, P12 Stack2 
H(LookupBlockIndex(12)).Pipro := False; 

H(LookupBlockIndex(12)).VisitFalse; 

H(LookupBlockIndex(12)).ChildrenJist := (13,14,15,16,18,Others => Nill); 
H(LookupBlockIndex(12)).ComponentJist := (Stack2_obj,Others => Nill); 
H(LookupBlockIndex(12)).ProfileJist := (110,2201,220,3211,Others => Nill); 

- Profile index 1,2,3,4,6,7, P13 , Stackl, Queue, Ring 
H(LookupBlockIndex(13)).Pipro := False; 

H(LookupBlockIndex(13)).Visit := False; 

H(LookupBlockIndex(13)).ChildrenJist (15,16,18,Others => Nill); 

H(LookupB!ockIndex(13)).ComponentJist := (Stack l_obj,Ring_obj,Queue_obj,Others => Nill); 
H(LookupBiockIndex(13)).ProfileJist(110,2201,220,3211,3301,3210,Others => Nill); 

- Profile index 1,2,3,4,5,6, PI4, Set 
H(LookupBlockIndex(14)),Pipro := False; 

H(LookupBlockIndex(14)).Visit := False; 

H(LookupBlockIndex(14)).ChildrenJist := (15,Others => Nill); 
H(LookupBlockIndex(14)).ComponentJist := (Set_obj,Others => Nill); 
H(LookupBlockIndex(14)).ProfileJist := (110,2201,220,3210,321 l,330,3301,0thers => Nill); 

- Profile index 1,2,3,4,5,6,7, P15a, Array, Bag, List], List2 
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H(LookupBlockIndex(15)).Pipro := False; 

H(LookupBl(xkIndex(15)). Visit := False; 

H(LookupBlockIndex(15)).ChildrenJist := (Others => Nill); 

H(LookupBlockIndex(15)).ComponentJist := (Array_obj,Bag_obj,Listl_obj,List2_obj,Others => Nill) 
H(LookupBlocklndex(15)).ProfileJist := ( 1 10,2201,220,321 ],330,3301,3210,0thers => Nill); 

— Profile index 1,2,3,4,6,7,9, PI6, Deque 
H(LookupBlockIndex(16)).Pipro := False; 

H(LookupBlocklndex(16)). Visit := False; 

H(LookupBlockIndex(16)).ChildrenJist := (18,Others => Nill); 

H(LookupBlockIndex(16)).Component Jist := (Deque obj,Others => Nill); 
H(LookupBlockIndex(16)).ProfileJist := ( 1 10,2201,220,3211,3301,3210, 

4221,Others=>Nill); 


- Profile index 1,2,3,5,8, P17, Bintl 
H(LookupBlockIndex(17)).Pipro := False; 

H(LookupBlockIndex(17)).Visit ;= False; 

H(LookupBlockIndex(17)).Children_list ;= (Others => Nill); 
H(LookupBlockIndex(17)).Component_list := (Bintl obj,Others => Nill); 
H(LookupBlocklndex( 17)).ProfileJist := (110,2201,220,330,4311, 

Others => Nill); 

- Profile index 1,2,3,4,6,7,8,9, P18, Bint2 
H(LookupBlockIndex(18)).Pipro := False; 

H(LookupBlockIndex(l 8)).Visit ;= False; 

H(LookupBlockIndex(18)).Children_list := (Others => Nill); 
H(LookupBlockIndex(18)).Coinponent_list := (Bint2_obj,Others => Nill); 
H(LookupBlocklndex(18)).Profile_list := ( 1 10,2201,220,3211,3301,3210,431 1 , 4221 , 

Others => Nill); 

End IntializeSwb; 


End Swb_pkg; 


— Module Name: getquery.a 

— Description: This module initialize stack query data. 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

— Verified as a first prototyped 

With Global_def; Use Global_def; 

With Swb_def_pkg; Use Swb_def_j)kg; 

With Floatio; Use Float Jo; 

With Integer io; Use Integer io; 

With Text io; Use Text io; 

Package Query_Processing_pkg is 

Procedure Get_Query(Q: out QC; Stable: in out Sort_table_def); 
End Query_Processing_pkg; 

Package body Query_processing_pkg is 

Procedure Get_Query(Q: out QC; Stable; in out Sort_table_de0 is 
Begin 
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“ Query spec 

— op empty -> Stack 
Q.C)ps(l). Profile := 110; 

Q.Ops(l).Symbol := "Empty 
Q.Ops(l).rs:= 21; 

Q.Ops(l).dms(l) := Nill; 

— op top Stack -> Nat 
Q.Ops(4).Profile := 220; 

Q.Ops(4).Symbol := "Top 
Q.Ops(4).rs := 22; - Nat alias to sortid 3 
Q.Ops(4).dms(l) := 21; 

Q.Ops(4).dms(2) := Nill; 

— op push Nat Stack -> Stack 
Q.Ops(2).Profile := 3211; 

Q.Ops(2). Symbol := "Push "; 

Q.C)ps(2).rs := 21; 

Q.Ops(2).dms(l) := 22; - Nat alias to sortid 3 
Q.Ops(2).dms(2) ;= 21; 

Q.Ops(2).dms(3) := Nill; 

-- op pop Stack -> Stack 
Q.Ops(3).Profile ;= 2201; 

Q.Ops(3). Symbol ;= "Pop "; 

Q.Ops(3).rs := 21; 

Q.Ops(3).dms(l) := 21; 

Q.Ops(3).dms(2) := Nill; 

— op depthof: Stack -> Nat 
Q.C)ps(5).Profile ;= 220; 

Q.Ops(5).Symbol := "Depthof 
Q.C)ps(5).rs := 22; 

Q.Ops(5).dms(l) := 21; 

Q.Ops(5).dms(2) := Nill; 

Q.Num_ops := 4; 

Q.Num_tcases := 1; 

Q.Geq(l) ProfileLsst := (220,3211,110,2201, Others => Nill); 

Q.Geq(l).Eqtext "Top(Push(l,Empty)) == Top(Pop(Push(6,Push(l,Empty)))) 

Q.Geq(2).ProfileT.ist := (220,3211,110,Others =>Nill); 

Q.Geq(2)Eqtext := "Depthof(Push(l,Push(2,Push(3,Empty))))== 3 

Q.KeywordList (Kw_Booch,Kw_DataStructure,Kw_Stack,Others => Nill); 
Q.ProfileList ;= (2201,3211,110,220,0thers => Nill); 


Q.Geq(l).Status := Unvoid; 
Q.Geq(2).Status := Unvoid, 
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-- Initialize predefine sort 
Stable := 

(5,((1, 

"FLOAT ",1,Basic,l,Nill,(2,3,others => Nill),(others =>Nill), 

(others => ’ ‘)), 

( 2 , 

"INT ",1 ,Basic,2,Nill,(3,others => Nill),(others => Nill), 

(others => ’ ’)), 

(3, 

"NAT ", 1 ,Basic,3,Nill,(others => NilI),(others=> Nill), 

(others => ’')), 

(4, 

"BOOL ",4,Basic,l ,Nill,(others => Nill),(others=> Nill), 

(others => ’')), 

(5, 

"CHAR ",5,Basic,l,Nill,(others => Nill),(others=> Nill), 

(others => ’ ’)), 

others -> - To be initialized by program 
(Nill, 

" ",Nill,Nill,Nill,Nill,(others=>Nill),(others=>NiIl), 

(others => ’ ’)))); 


— Now initialize sort table for query sort 

Stable.Num_of_sort := Stable.Num_of_sort + 1; 
Stable.Sort_table(21).Sort_id := 21; 

Stable.Sort_table(21).Sort_Symbol ;= "Stack 
Stable. SortJable(21).Main_sort := 21; 

Stable. Sort_table(21).Sort_rank := 1; 

Stable.Sort__table(21).Sort_type := Unconfined; 
Stable. Sort_table(21).Csortid := Nill; 

Stable. Sort_table(21).Children_ids(l) := Nill; 

Stable.Sort_table(21).Parent_ids(l) := Nill; 

Stable.Num of sort := Stable.Num of sort + 1; 
Stable. Sort_table(22) := Stable.Sort Jable(Nat_type); 

End Get Queiy ; 

End Query_processing_pkg; ~ End of query processing 


— Module Name: fresult.a 

— Description: This module calculated the total rank and formulate the 

— result and output to the user 

— Author: Nguyen Doan 

— History: Nov, 6 1995 

— Verified as a first prototyped 


With GlobaLdef; Use Global_def; 
With text io; Use text io; 

With integer_io; Use integer_io; 
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With Float io; Use Float_io; 


Package Formulate_Result_Outpul_pkg is 

Procedure Display_invalid_operations(Q: Qc;Profile_err: Profile_err_list); 
Procedure Sort_Display_Result(SortArray :In Out Asort_Array;Count: Natural); 
Procedure Calculate_total_rank(V : Signature^Map; Q: Qc; C:SWC; 
Idx,Nuin_vmaps: Natural;SorlArray : In Out Asort_Array; 
KeywordRank,ProfileRank: Float); 

End Fonnulate_Result_Output_pkg; 

Package body Fonnulate_Result_Output_pkg is 

Procedure Display Jnvalid_operations(Q: Qc;Profile_err: Profile_errJist) is 
Begin 

If Profi!e_erT(l) /= Nill then 
Newline; 

Put("The following operation(s) is unknown:"); Newsline; 

Fori in l.,Profile_errJist'Length 
Loop 

If Profile_err(i) = Nill then 
Exit; 

Else 

Fork in L.Q.Num_ops 
Loop 

If Q.Ops(k).Profile = Profile_err(i) then 
Put(String(Q.Ops(k).Symbol)); Newjine; 

End If; 

End Loop; 

End If; 

End Loop; 

End If; 

End Display_invalid_operations; 

Procedure Sort_Display_Result(SortArray :In Out Asort_Array;Count: Natural) is 
Smallest: Integer; 

Temp : Sort_Rank; 

Begin 

- Selection Sort 
Forj in 1 ..Count-1 
Loop 

Smallest := j; 

For qin j+1 .. Count 
Loop 

If SortArray(q).MaxoverallRank < SortArray(Smallest).MaxoverallRank then 
Smallest := q; 

End If; 

End Loop; 

If smallest > j then 
Temp := SortArray(Smallest); 

SortArray(Smallest)SortArray(j); 

SortArray(j) := Temp; 
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End If; 

End Loop; 

Now display result 
For i in reverse 1 ..Count 
Loop 

If SortArray(i).Mapnum /= 0 then 
New_line; 

put(’’Find Component: "); 

put(String(SortArray(i).ModuleName)); Newjine; 

putC'Using Map Number: "); 
put(SortArray(i),Mapnum); Newjine; 

put("Key wordRank: "); 

put(Float(SortArray (i). SelKey wordRank),4,1); 
put(", ProfileRank:"); 

put(Float(SortArray (i). SelProfileRank),4,1 );New_line; 
putC’SignatureRank: 

put(Float(SortArray (i).SelSignatureRank),4,1); 
put(", SemanticRank :"); 

put(Float(SortArray (i).SelSemanticRank),4,1 );New_line; 
put(’The ComponentRank:"); 

put(Float(SortAiTay (i).MaxoveralIRank),4,1 );New_line; 

Else 

Newjine; 

putC'Find Component: 

put(String(SortArray(i).ModuleName)); Newjine; 
putC’Key wordRank: "); 
put(Float(SortArray(i).SelKeywordRank),4,l); 
put(", ProfileRank: ”); 

put(Float(SortArray(i).SelProfileRank),4,1 );New Jine; 
put("No map is found!”);NewJine; 

End If; 

End Loop; 

End Sort Display Result; 

Procedure CalculateJotaI_rank(V : Signature_Map; Q: Qc; C:SWC; 
Idx,Num_vmaps: Natural;SortArray : In Out Asort Array; 
KeywordRank,ProfileRank: Float) is 
Interm Rank, MaxoverallRank : Float := 0.0; 

SelSemanticRank,SelSignatureRank : Float := 0.0; 

Mapnum : Natural := 0; 

Begin 

SortArTay(idx).ModuleName := C.Obj filename; 
SortArray(idx)-SelKeywordRank := KeywordRank; 
SortArray(idx).SelProfileRank := ProfileRank; 

For i in L.Num vmaps 
Loop 

Interm Rank := 
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ProfileRank * KeywordRank * v(i).SemanticRank * v(i).SignatiireRank; 
if Interni_Rank > SortArray(idx).MaxoverallRank then 
SortArray(idx).SelSignatureRank := v(i).SignatureRank; 
SortArray(idx).SelSemanticRank := v(i).SemanticRank; 
SortAiTay(idx).MaxoverallRank := Interm^Rank; 

SortArray(idx).Mapnuni := i; 

End If; 
end loop; 

If SortArray(Idx).SelSenianticRank <= 0.0 then 
“ Recaculate SelSignatureRank 
SelSignatureRank := 0.0; 

Fori in l. Num vmaps 
Loop 

If SortArray(idx).SelSignatureRank <= V(i).SignatureRank then 
SortArray(idx).SelSignatureRank := V(i).SignatureRank; 
SortAiTay(idx).Mapntim := i; 

End If; 

End Loop; 

End If; 

End Calculate_total_rank; 

End Formulate_Result_Output j)kg; — End of Forniulate_Result_Output_pkg 
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APPENDIX D - RUNOBJ AND SCS BUILD FILES 


# This is runobj script file. It is invoked from the SCS to do perform term rewriting on the 

# translate ground equations. 

# Author: Nguyen, Doan 

# Date: 12/4/95 


obj < testfile.obj | grep result | sed -e ‘s/.*result //’ > testrun.dat 


# This is SCS build file. It is used to build the SCS prototype 

# Author: Nguyen, Doan 

# Date: 12/4/95 

a.cleanlib 


ada gldef a; ada asable.a; ada semops.a ;ada utilop.a; ada utilso.a; 
ada nsa.a; ada sigmat.a; ada semata; ada fresult.a; ada swb_def.a; 
ada getquery.a; ada swb.a; ada init.a; ada scs.a 
a.ld Main -o SCS 
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APPENDIX E - A PROOF FOR THEOREM 1 


In this appendix contains two parts. First, we will show that s is an equivalence 
relation on the transitivity-closure(synimetry-closure( < )). Secondly, we will prove the 
Theorem 1. 

A. ASSUMPTION: The subsort relation < is a partial ordering relation. 

B. DEFINITION: The relation = is defined to be the transitive closure of sym¬ 
metry closure of the symmetry closure of < . 

A. SHOW s IS AN EQUIVALENCE RELATION 

• Reflexivity: Yes, because x < x. x = x. 

• Symmetry: Yes, because the symmetric closure of any relation is symmetric 
and R < transitive closure R. 

• Transitivity: Yes, because the transitive closure of any relation is transitive for 
any relation R. 

The important consequence of this equivalence relation is that sort group are 
equivalence classes and any two equivalence classes must be equal or disjoint. This is 
important for our next proof 

B. PROOF OF THEOREM 1 

Theorem 1: Given a query operation and a component operation with their corre¬ 
sponding profile values, if these profile values are not equal, then these operations can not 
possibly be related by a signature match. 

Proof: 

• Case 1: Consider query and component operators which do not have the same 
number of sort occurrences. The profile values for both operators are different 
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by rule 1 of definition 4. 

By the requirement 7 of section IV.D, the number of argurment sorts, n, must 
be the same for both operators. Therefore, these query and component opera¬ 
tors can not be matched. 

Case 2: Consider query and component operators which have the same number 
of sort occurences. The number of sort group in query operator is less than 
component operator. The profile values for boA operators are different by rules 
2, 3, and 4 of definition 4. 

Since the number of sort groups of query is less than the sort groups of compo¬ 
nent, the correspond mapping will be result in an non injective map. By the 
requirement 1 of section IV.D, the sort mapping must be injective. Therefore, 
these query and component operators can not be matched. 

• Case 3: Consider query and component operators which have the same number 
of sort occurrences. The number of sort groups in query operator is greater than 
component operator. The profile values for both operators are different by rules 
2, 3, and 4 of definition 4. 

Since the number of sort groups is of query operator is greater than the sort 
groups of component operator, the correspond mapping will be result in an non 
injective map. By the requirement 1 of section IV.D, the sort mapping must be 
injective. Therefore, these query and component operators can not be matched. 

• Case 4: Consider query and component operators which have the same number 
of sort occurrences and the same number of sort groups. The cardinality of one 
sort group in query operator is not equal to a cardinality of any operator’s sort 
groups. The profile values for both operators are different by rules 2, 3, and 4 
of definition 4. 

Since one query sort group has a cardinality different from any other sort group 
of the component, there are one of the two possible violations of the mapping 
can be happened. First, the injective sort mapping is violated. One of the sort in 
this sort group in the query would map to more than two components sorts or 
two or more sort in this sort group in the query would map to one component’s 
sort. Second, the requirement 7 of section IV.D is violated if any sort from 
query or component operator is left dangling. Therefore, these query and com¬ 
ponent operators can not be matched. 
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